Skip to main content

Third-party app (OAuth / OIDC)

Logto's third-party application integration enables you to leverage Logto as an Identity Provider (IdP) for external applications.

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 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 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."

Logto is an identity service built on the OpenID Connect (OIDC) protocol, providing both authentication and authorization capabilities. This make integrating an OIDC third-party app as straightforward as traditional web application.

Thus due to OIDC builds upon OAuth 2.0 adding an authentication layer, you can also integrate third-party app using OAuth protocol.

Create a third-party application in Logto​

  1. Go to Console > Applications.
  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 / OAuth configurations​

  1. Provide the redirect URI 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 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 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) for secure authorization instead.

  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 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.

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:

For security reasons, all the OIDC third-party applications will be redirected to a consent screen for user authorization after they are authenticated by Logto.

All the third-party requested user profile permissions, API resource scopes, organization permissions, 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.

consent screen

FAQs​

Logto uses Role-Based Access Control (RBAC) to manage user permissions. On the consent screen, only scopes (permissions) already assigned to the user—through their roles—will be displayed. If a third-party app requests scopes the user doesn’t have, those will be excluded to prevent unauthorized consent.

To manage this:

  • Define global roles or organization roles with specific scopes.
  • Assign roles to users based on their access needs.
  • Users will inherit scopes from their roles automatically.

Use case: Integrate Apache Answer to launch a community for your users

Using Logto as an third-party identity provider (IdP)