Bring Your Own Auth

If your organization uses its own identity system—whether homegrown or from another vendor—you can bring that into Descope and wire it to an MCP server so your product APIs and features are exposed to LLMs with proper OAuth tokens, scopes, and DCR/CIMD client registration.

Why Bring Your Own Auth?

Enterprises often have:

• A homegrown auth system or an existing IdP (e.g., Okta, Azure AD, Auth0)
• Product UIs and APIs already protected by that system
• A desire to expose the same product to MCP clients (IDEs, agents, chat) without maintaining a second auth stack

Descope lets you keep your existing auth as the source of truth and use it to drive MCP server authorization: users sign in with your system, and Descope issues MCP-ready OAuth tokens with the right scopes and audience so your MCP server can enforce access consistently.

How MCP Server Auth Works with Descope

MCP server authentication is typically done via the OAuth 2.1 authorization code flow. Descope acts as the authorization server for your MCP server:

• You configure an MCP server in Descope with a well-known endpoint, scopes, and client registration (DCR and/or CIMD).
• MCP clients discover your server, register (via CIMD or DCR), and send users through the authorization code flow.
• Your user consent flow in Descope is where you plug in your own auth: instead of (or in addition to) Descope's native methods, you can validate the user against your existing system and then issue a Descope session/JWT so the MCP client receives a valid OAuth access token for your MCP server.

Two Ways to Use Existing IdP

You can use your existing auth with Descope as the authorization server for your MCP server in two main ways:

1. Use Identity Federation (OIDC or SAML)

With this method, Descope acts as the OAuth authorization server for your MCP server. Then, when a user connects an MCP client:

1. The client redirects the user to your Descope user consent flow.
2. In that flow, you authenticate the user with your system (e.g., redirect to your IdP as either a custom OAuth provider or tenant-level SSO provider).
3. After successful auth, the flow continues in Descope (e.g., consent screen, custom claims), and the flow ends with the End action, which issues a Descope session and JWT.
4. The MCP client exchanges the authorization code for an access token; that token is valid for your MCP server and carries the scopes and claims you configured.

2. Homegrown Auth (no OIDC/SAML)

When your auth system is homegrown or a third-party that doesn't support OIDC or SAML, you can still use it in the consent flow by collecting credentials or a pre-existing token, validating them against your API, and then issuing a Descope JWT with a Generate JWT action.

Collecting User Credentials in the Flow

The Generate JWT action creates or finds a user in Descope using either form.email or form.externalId from the flow context. One of these values must be set before the Generate JWT step runs.

To do this:

1. Add a Screen where the user enters their credentials (for example, email/password or username/password)
2. Validate the credentials by sending them to your authentication API using a Generic HTTP Connector
3. Map the response (such as user ID or email) into the flow context
4. Add a Generate JWT action to provision the user in Descope and issue a session token

Using an Existing Session Token

If the user already has a session token (such as a custom JWT or opaque token stored in a cookie), the flow can reuse it.

1. Read the token in the flow — for example via dynamic_val or automatically from a cookie when the flow runs on the same custom domain
2. Validate the token by calling your API with a Generic HTTP Connector (e.g., GET /userinfo or POST /introspect)
3. Map the response (such as user ID or email) into the flow context
4. Issue a Descope JWT using the Generate JWT action

The MCP client can then continue the authorization code flow using the returned Descope JWT.