Bring Your Own Auth for MCP
If your organization already runs its own identity system, homegrown or from another vendor, you can keep it and still protect an MCP server with Descope. Users sign in with your system, and Descope issues MCP-ready OAuth tokens with the right scopes, audience, and DCR/CIMD client registration.
The ways to connect your login system aren't specific to MCP. The general Bring Your Own Auth page covers them. This page covers what changes when the Flow behind them protects an MCP server.
Why Bring Your Own Auth for MCP?
Your product UIs and APIs are probably already protected by your login system. Exposing the same product to MCP clients, such as IDEs, agents, and chat apps, shouldn't mean a second auth stack or a user migration.
With Bring Your Own Auth, your system stays the source of truth for who a user is. Descope acts as the OAuth authorization server for your MCP server, so your server checks Descope tokens the same way for every MCP client.
How MCP Server Auth Works with Descope
MCP clients authenticate with the OAuth 2.1 authorization code flow, and Descope plays the authorization server:
- You configure an MCP server in Descope with a well-known endpoint, scopes, and client registration through DCR, CIMD, or both.
- MCP clients discover your server, register, and send users to Descope's authorization URL.
- Descope runs your user consent flow, signs the user in, and asks for consent to the requested scopes.
- Descope redirects back to the MCP client with an authorization code, and the client exchanges the code for an access token scoped to your MCP server.
The user consent flow is where your login system plugs in. Inside it, you can federate your IdP over OIDC or SAML, or hand off to your login page with External Authentication. You can also check credentials or an existing session against your API and issue the session with Generate JWT. Choosing an Approach explains which option fits your system.
Select any step to see what happens.
Tenant Context with Connections
If your MCP server uses Connections to manage credentials for downstream services, the token type you store depends on tenant context. With External Authentication, you can pass selectedTenantId when your backend completes the request. Passing it early sets the tenant before the MCP and Connections flows store or fetch tokens.
If the tenant doesn't exist yet, create it with the Management SDK or API before your backend completes External Authentication, because tenant context decides which token type Connections stores.
Next Steps
To set up the login side, follow Bring Your Own Auth. To build the MCP server itself, start with the MCP server guide.