refactor: third-party app

docs/integrate-logto/third-party-applications/README.mdx

@@ -12,7 +12,7 @@ Logto's third-party application integration enables you to leverage Logto as an
 
 An Identity Provider (IdP) is a service that verifies user identities and manages their login credentials. After confirming a user's identity, the IdP generates authentication tokens or assertions and allows the user to access various applications or services without needing to log in again.
 
-Unlike the applications you created in the [Integrate Logto into your application](/integrate-logto/integrate-logto-into-your-application) guide that are developed and fully controlled by you, third-party applications are independent services developed by external developers or business partners.
+Unlike the applications you created in the [Integrate Logto into your application](/integrate-logto/integrate-logto-into-your-application) guide that are developed and fully controlled by you, third-party applications are independent services developed by external developers or business partners. When users sign in to a third-party application via Logto (e.g., by clicking "Sign in with Logto"), they will be presented with a [consent screen](/end-user-flows/consent-screen) asking them to review and authorize the requested user and organization permissions before access is granted.
 
 This integration approach is well-suited for common business scenarios. You can enable users to access partner applications using their Logto accounts, just like how enterprise users sign in to Slack with Google Workspace. You can also build an open platform where third-party applications can add "Sign in with Logto" functionality, similar to "Sign in with Google."
 
@@ -23,40 +23,31 @@ Thus due to OIDC builds upon [OAuth 2.0](https://auth.wiki/oauth-2.0) adding an
 ## Create an third-party application in Logto \{#create-an-third-party-application-in-logto}
 
 1. Go to <CloudLink to="/applications">Console > Applications</CloudLink>.
-2. Click on the "Create application" button. Select "Third-party app" as the application type and choose one of the following integration protocols:
-   - OIDC / OAuth
+2. Click on the "Create application" button. Select "**Third-party app**" as the application type, then choose one of the following integration options based on your application architecture:
+   - **Traditional web app**: For server-side web applications that can securely store client secrets. This is the most common type for third-party integrations, such as enterprise SaaS platforms or partner portals that handle authentication on the server side.
+   - **Single page app (SPA)**: For client-side web applications that run entirely in the user's browser and cannot securely store client secrets. In this scenario, the client obtains tokens directly from the authorization server without going through a backend. A typical example is MCP (Model Context Protocol) integrations, where the MCP Client initiates authentication directly with the auth server to access various MCP Servers—the MCP Server providers don't control the client applications.
+   - **Native app**: For mobile or desktop applications that run on user devices and cannot securely store client secrets. Examples include desktop applications like Claude Desktop or VS Code that need to authenticate users to access third-party services.
 3. Enter a name and description for your application and click on the “Create” button. A new third-party application will be created.
 
 All created third-party applications will be catalogued on the Applications page under the "Third-party apps" tab. This arrangement helps you distinguish them from your own applications, making it easier to manage all your applications in one place.
 
-## Set up the OIDC configurations \{#set-up-the-oidc-configurations}
-
-:::note
-Before setting up the OIDC configurations, please ensure you've [created an OIDC third-party application](/quick-starts/third-party-oidc).
-:::
+## Set up the OIDC / OAuth configurations \{#set-up-the-oidc-configurations}
 
 1. Provide the [**redirect URI**](/integrate-logto/application-data-structure#redirect-uris) of your OIDC third-party application. This is the URL that the third-party application will redirect users to after they are authenticated by Logto.
    You can usually find this information in the third-party application's IdP connection settings page.
 
-2. Retrieve the [**client ID**](/integrate-logto/application-data-structure#application-id) and [**client secret**](/integrate-logto/application-data-structure#application-secret) from Logto application details page and enter them into your service provider's IdP connection settings page.
+2. Retrieve the [**client ID**](/integrate-logto/application-data-structure#application-id) from Logto application details page and enter it into your service provider's IdP connection settings page.
+
+   - For **traditional web apps**, also retrieve the [**client secret**](/integrate-logto/application-data-structure#application-secret) and provide it to your service provider, as server-side applications can securely store secrets.
+   - For **single page apps (SPA)** and **native apps**, client secret is not required since these applications cannot securely store secrets. They use [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) for secure authorization instead.
 
 3. Retrieve the [**authorization endpoint**](/integrate-logto/application-data-structure#authorization-endpoint) and [**token endpoint**](/integrate-logto/application-data-structure#token-endpoint) from Logto application details page and provide them to your service provider.
    If your service provider supports OIDC discovery, you can simply copy the **discovery endpoint** from Logto application details page and provide it to your service provider. The service provider will be able to retrieve all the up to date OIDC authentication information from the discovery endpoint automatically.
    Otherwise, click on the **Show endpoint details** button to view all the OIDC authentication endpoints.
 
-## Consent screen for OIDC third-party applications \{#consent-screen-for-oidc-third-party-applications}
-
-For security reasons, all the OIDC third-party applications will be redirected to a [consent screen](/end-user-flows/consent-screen) for user authorization after they are authenticated by Logto.
-
-All the third-party requested [user profile permissions](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API resource scopes](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [organization permissions](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes), and organization membership information will be displayed on the consent screen.
-
-These requested permissions will be granted to the third-party applications only after the user clicks on the "Authorize" button.
-
-<center>
-  <img src="/img/assets/consent-screen.webp" alt="consent screen" width={500} />
-</center>
+## Manage permissions and branding \{#manage-permissions-and-branding}
 
-## Further actions \{#further-actions}
+Once the OIDC configurations are set up, you can manage what permissions the third-party application can request and customize the branding of the consent screen:
 
 <DocCardList
   items={[
@@ -82,6 +73,18 @@ These requested permissions will be granted to the third-party applications only
   ]}
 />
 
+## Consent screen for third-party applications \{#consent-screen-for-third-party-applications}
+
+For security reasons, all the OIDC third-party applications will be redirected to a [consent screen](/end-user-flows/consent-screen) for user authorization after they are authenticated by Logto.
+
+All the third-party requested [user profile permissions](/integrate-logto/third-party-applications/permission-management#user-permissions-user-profile-scopes), [API resource scopes](/integrate-logto/third-party-applications/permission-management#api-resource-permissions-api-resource-scopes), [organization permissions](/integrate-logto/third-party-applications/permission-management#organization-permissions-organization-scopes), and organization membership information will be displayed on the consent screen.
+
+These requested permissions will be granted to the third-party applications only after the user clicks on the "Authorize" button.
+
+<center>
+  <img src="/img/assets/consent-screen.webp" alt="consent screen" width={500} />
+</center>
+
 ## FAQs \{#faqs}
 
 <details>

docs/quick-starts/third-party/_quick-starts-reference.md

@@ -0,0 +1,10 @@
+Under the hood, a third-party app is just a standard OAuth 2.0 / OIDC client. This means you (or the third-party developer) can use any OAuth 2.0 / OIDC library or framework to integrate with Logto.
+
+If you're not familiar with OAuth 2.0 or OIDC, you can start by following one of our quick start guides based on your application type.
+
+A few things to keep in mind:
+
+1. Most of our quick start guides are written for first-party apps, but you can still use them as a reference for third-party app integration.
+2. The main difference is that third-party apps will show a consent screen, asking users for explicit permission to access their data.
+
+You can find more information in our [quick start guides](/quick-starts).

docs/quick-starts/third-party/native/README.mdx

@@ -0,0 +1,85 @@
+---
+slug: /quick-starts/third-party-native
+sidebar_label: Third-party app (Native app)
+sidebar_custom_props:
+  description: Integrate a third-party native (mobile/desktop) application using OIDC / OAuth protocol with PKCE.
+  logoFilename: 'native.svg'
+---
+
+import AuthorizationIcon from '@site/src/assets/authorization.svg';
+import CustomizationIcon from '@site/src/assets/customization.svg';
+
+import QuickStartsReference from '../_quick-starts-reference.md';
+
+# Third-party app integration: Native app
+
+Use Logto as your identity provider (IdP) to integrate third-party native applications (mobile or desktop) via OpenID Connect (OIDC) or OAuth 2.0 protocol.
+
+Native apps are mobile or desktop applications that run on user devices. Since they cannot securely store client secrets, they use [PKCE (Proof Key for Code Exchange)](https://auth.wiki/pkce) for secure authorization. Examples include desktop applications like Claude Desktop or VS Code that need to authenticate users to access third-party services.
+
+## Create a third-party native app in Logto \{#create-a-third-party-native-app-in-logto}
+
+1. Go to <CloudLink to="/applications">Console > Applications</CloudLink>.
+
+2. Select "Third-party app > Third-party app (Native app)" as the application type.
+
+   - If this is the first time you create an application, click on the **View all** link to see all application types.
+
+   - Otherwise, click on the **Create application** button on the top right corner of the page and select "Third-party app > Third-party app (Native app)" as the application type.
+
+3. Enter a **name** and **description** for your application and click on the **Create** button. A new third-party native app will be created.
+
+## Set up the OIDC / OAuth configurations \{#set-up-the-oidc-oauth-configurations}
+
+To configure Logto as an IdP for your third-party native application:
+
+1. Provide the **redirect URI** of your third-party application. For native apps, this is typically a custom URL scheme (e.g., `myapp://callback`) or a universal/app link. You can usually find this information in the third-party application's IdP connection settings page. Logto supports multiple redirect URIs—click the **Add another** button to add more.
+
+2. Retrieve the **client ID** from Logto application details page and enter it into your service provider's IdP connection settings page.
+
+3. Retrieve the **authorization endpoint** and **token endpoint** from Logto application details page and provide them to your service provider.
+
+   - If your service provider supports OIDC discovery, you can simply copy the **discovery endpoint** from Logto application details page and provide it to your service provider. The service provider will automatically retrieve all OIDC authentication information from the discovery endpoint.
+   - Otherwise, click on the **Show endpoint details** button to view all the OIDC authentication endpoints.
+
+4. Ensure the third-party application is configured to use **PKCE** (Proof Key for Code Exchange) during the authorization flow. Most modern OAuth/OIDC libraries support PKCE out of the box.
+
+---
+
+<QuickStartsReference />
+
+## Manage permissions and branding \{#manage-permissions-and-branding}
+
+Once the OIDC configurations are set up, you can manage what permissions the third-party application can request and customize the branding of the consent screen:
+
+<DocCardList
+  items={[
+    {
+      type: 'link',
+      label: 'Permission management',
+      href: '/integrate-logto/third-party-applications/permission-management',
+      description: 'Learn how to manage permissions for your OIDC third-party application.',
+      customProps: {
+        icon: <AuthorizationIcon width={20} height={20} />,
+      },
+    },
+    {
+      type: 'link',
+      label: 'Consent screen branding',
+      href: '/integrate-logto/third-party-applications/consent-screen-branding',
+      description:
+        'Personalize the consent screen appearance to match your brand identity and provide a consistent user experience.',
+      customProps: {
+        icon: <CustomizationIcon width={20} height={20} />,
+      },
+    },
+  ]}
+/>
+
+## Manage your third-party applications \{#manage-your-third-party-applications}
+
+All third-party applications are listed on the **Applications** page under the **Third-party apps** tab, making it easy to distinguish them from first-party applications.
+
+## Further readings \{#further-readings}
+
+<Url href="/integrate-logto/third-party-applications">Third-party applications</Url>