Wiring MCP to Your IdP

Connecting MCP to Enterprise Identity

In Part 1 of this series we introduced the Model Context Protocol and the security questions it raises for enterprises. Now we turn to the practical challenge at the heart of every deployment: wiring an MCP server to your organization's Identity Provider (IdP).

Getting this integration right means AI agents can authenticate through the same trusted infrastructure that protects every other application in your environment — no shadow credential stores, no one-off auth logic, and no gaps in your audit trail. This article covers direct OAuth flows, advanced token exchange for delegated access, and the division of responsibilities between the IdP and MCP resource servers.

Enterprise Identity Integration Overview

The architecture follows a clean OAuth 2.1 / OIDC pattern with two clearly defined roles:

• The IdP acts as the OAuth 2 / OIDC Authorization Server, authenticating users and issuing tokens.
• MCP servers function as OAuth 2 Resource Servers, consuming and validating those tokens before granting data access.
• The IdP is the single source of truth for identity and access across both human and agent-driven interactions.
• MCP servers stay focused on enforcing data access — never on minting credentials.

By using your existing IdP as the authorization server, you can leverage features like single sign-on, multi-factor auth, centralized user management, and compliance auditing for all AI agent interactions. OIDC builds on OAuth 2.0 to provide an identity layer with ID tokens for user info, enabling SSO between applications. When a user or agent authenticates via the IdP, you get an access token for calling the MCP API and an ID token to identify the user.

Benefits of IdP Integration

Routing MCP authentication through your existing IdP delivers immediate, measurable advantages:

OIDC and the Identity Layer

OpenID Connect builds on top of OAuth 2.0 to provide a standardized identity layer. While OAuth handles authorization (what you can access), OIDC adds authentication (who you are) through ID tokens.

This is what enables SSO between applications: a single authentication event at the IdP produces tokens that any OIDC-compliant service — including MCP servers — can verify and trust. The result is a unified identity model that spans human users and AI agents alike.

Authorization Server vs. Resource Server

It's crucial to architect the integration with a strong separation of concerns between the IdP (Authorization Server) and the MCP server (Resource Server). All OAuth 2.1 interactions — authorization codes, token issuance, refresh — occur at the IdP. The MCP server's job is to validate incoming tokens and serve data if the token is valid and sufficiently privileged.

This mirrors the classic web API model: clients obtain a bearer token from a central auth server and then call protected APIs with that token. The MCP server can remain stateless regarding auth — no token database needed — simply verifying token signatures or introspecting tokens on each request.

One immediate benefit is consistency and security. All policies — password rules, 2FA requirements, session lifetime — are enforced by the IdP globally. If an employee leaves or roles change, their access to MCP-connected tools is updated centrally. This design aligns with Zero Trust principles: each request to the MCP resource is individually authenticated via a token that the IdP issued and the MCP validates.

If the MCP server receives a request without a valid token, it should reject it with an HTTP 401 and guide the client on how to obtain a token. For example:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="MCP",
  error="invalid_token",
  authorization_uri="https://<your-idp>/oauth/authorize",
  discovery_uri="https://<your-idp>/.well-known/oauth-authorization-server",
  token_type="Bearer"

This way, any MCP client — including AI agents or developer tools — knows where to initiate the OAuth flow to get a proper token for the next request.

User Authorization Code Flow (Interactive)

When a human user needs to grant an AI agent access to an MCP-protected resource on their behalf, the standard OAuth 2.1 Authorization Code flow with PKCE applies. Here is the complete walkthrough:

1. 1
   Client Registration

   Register the AI application as an OAuth client in your IdP. Configure redirect URIs, permit the Authorization Code grant with PKCE, and request OIDC scopes. Define custom scopes or audience identifiers that represent the MCP server's APIs.

2. 2
   Initiate Auth Flow

   When the agent needs an MCP tool, the client redirects the user to the IdP's /authorize URL with client ID, redirect URI, and requested scopes (e.g. mcp.read, mcp.tools.slack).

3. 3
   User Login & Consent

   The IdP authenticates the user via SSO and MFA (if configured). A consent screen appears if the application requests access on the user's behalf, unless pre-consented by policy.

4. 4
   Token Issuance

   The IdP issues an authorization code and redirects back. The client exchanges the code at the /token endpoint (using PKCE for public clients) to receive an access token, refresh token, and an ID token if OIDC scope was requested.

5. 5
   Call MCP Server

   The client invokes the MCP server's API with the header Authorization: Bearer <access_token>. The access token — JWT or opaque — is issued by the IdP and represents the user's granted rights.

6. 6
   Token Validation

   The MCP server validates the JWT signature using the IdP's JWKS keys, verifies expiration, issuer, and audience claims, and checks that the token has the necessary scopes for the requested operation. Opaque tokens can be introspected via the IdP's introspection endpoint.

7. 7
   Authorize Request

   If the token checks out, the MCP server allows the operation and returns data. If the token is missing or invalid, it returns 401 with a WWW-Authenticate header pointing to the IdP.

8. 8
   (Optional) Use ID Token

   The OIDC ID token lets the client know the user's identity (subject, email) for personalization or logging, without the MCP server needing its own user database.

Service-to-Service Client Credentials

Not all agentic AI scenarios involve an interactive user. Sometimes an AI agent service needs to authenticate itself for background tasks — a nightly data sync, index maintenance, or a headless agent running with a service identity. The OAuth 2.1 Client Credentials flow handles these machine-to-machine scenarios.

• Register a machine client in the IdP with Client Credentials grant enabled and a client ID / secret (or certificate).
• Grant the client the necessary scopes or audience to access the MCP resource (e.g. mcp.backup).
• The client calls the IdP's /token endpoint directly with its credentials — a server-to-server call with no user interaction.
• The IdP authenticates the client and issues an access token (no ID token, since there's no user). The token has the client as the subject.
• The service calls the MCP server with the bearer token. The MCP validates it the same way — signature, issuer, audience, scopes.

This flow allows internal services or headless AI processes to use MCP tools without a user context, fully tracked and managed by the IdP. You can revoke the client credentials or monitor usage at any time. OAuth 2.1 also enables modern security features like private key JWT or mutual TLS client authentication for these flows.

Token Exchange & Delegated Authorization

Direct OAuth flows cover single-service scenarios. But what happens in complex agentic workflows where one service calls another on behalf of the same user? For example, an AI agent queries a database via one MCP tool, then calls a CRM system through a different MCP tool — all under the original user's authority. The OAuth 2.0 Token Exchange (RFC 8693) enables this delegated authorization pattern.

Token Exchange lets a client swap an existing token for a new one with a different audience, scopes, or attributes — preserving the chain of trust without sharing the original token with services it wasn't intended for.

In practice, the on-behalf-of flow works like this:

1. 1
   Initial Token

   The user obtains an access token (Token A) from the IdP via the normal auth code flow. This token is intended for Service A (audience = Service A, e.g. an MCP tool).

2. 2
   Call to Service A

   The client calls Service A (MCP Tool A) with Token A. Service A validates it and processes the request.

3. 3
   Need to Call Service B

   To complete its operation, Service A needs data from Service B (another MCP tool or external API) on behalf of the same user. Service A acts as a client to Service B.

4. 4
   Token Exchange Request

   Service A sends a token exchange request to the IdP (grant_type=urn:ietf:params:oauth:grant-type:token-exchange), passing Token A as the subject_token and identifying Service B as the target audience. Service A authenticates itself with its own credentials.

5. 5
   IdP Validates & Issues Token B

   The IdP verifies Token A is valid and Service A is authorized for this exchange. If checks pass, it issues Token B — scoped for Service B, carrying the user's identity and an actor claim showing Service A is the delegating party.

6. 6
   Call to Service B

   Service A calls Service B with Token B. Service B validates it as any resource server would — checking signature, audience, and the user's authorization via delegation.

7. 7
   End-to-End Outcome

   The user's request is fulfilled without ever needing separate credentials for Service B. The user's identity and permissions flowed securely through the system using tokens, and each service only accepted tokens meant for itself.

Historical Context

Early drafts of the MCP specification expected every MCP server to function as its own mini OAuth server — handling token issuance, key management, and session state internally. The community quickly pushed back: bundling authorization logic into every data-access endpoint creates enormous surface area for security mistakes.

That feedback prompted a fundamental redesign. The latest version of the spec draws a clear separation between MCP responsibilities (resource exposure, tool invocation) and OAuth responsibilities (authentication, token issuance). This is the architecture enterprises should adopt.

Preparing for Trust Frameworks & Federation

By wiring your MCP server into your enterprise IdP, you've set a strong foundation for secure agentic AI integration. Every request an AI agent makes to your MCP-hosted tools is authenticated and authorized using the same centralized identity system that the rest of your enterprise relies on.

Looking forward, this integration prepares the ground for more advanced identity architectures. Federated identity (via protocols like OpenID Connect Federation 1.0) would allow your MCP server to accept tokens from a partner's IdP based on established trust relationships. Your MCP server can still behave as a resource server, but now it might trust multiple issuers — your enterprise IdP, a partner's IdP, or a higher-level federation authority.

Similarly, trust frameworks can be layered on top of OAuth/OIDC to enforce consistent security standards across all parties — requiring certain token claims or assurance levels. Because you've kept your MCP implementation aligned with standard OAuth 2.1 and OIDC practices, it will be compatible with these broader ecosystem extensions.