Published July 20, 2026Blog

MCP Authentication Explained: How OAuth Works in MCP - and How It Got Here

Table of contents

If you are implementing or evaluating MCP authentication in 2026, you are arriving after a fast-moving set of revisions. A lot of older material still describes a model that no longer applies. This post is the current map: what the 2025-11-25 Model Context Protocol specification requires, what each authentication and client-identification mechanism does, and why the design landed where it did.

The short version: MCP now uses OAuth 2.1 concepts in a resource-server model. MCP servers delegate authorization to a real authorization server, PKCE is mandatory for authorization-code flows, and clients identify themselves through pre-registration, Client ID Metadata Documents, Dynamic Client Registration, or manual entry in that order.

The short history that explains MCP authentication

The 2025-03-26 MCP specification made MCP servers act as their own OAuth authorization servers. Every team shipping an MCP server suddenly owned token issuance, client registration, key management, and OAuth edge cases. That was too much security machinery for most tool teams to implement correctly.

The 2025-06-18 specification changed the architecture. MCP servers became OAuth resource servers. They could delegate authorization to a proper authorization server. Discovery works through Protected Resource Metadata, and resource indicators bind tokens to the specific MCP server they are meant for, so a token minted for one MCP server should not be replayed against another.

The 2025-11-25 specification solved the remaining practical problem: how should an MCP client identify itself to an authorization server it has never met before? That is where Client ID Metadata Documents, or CIMD, became the preferred dynamic approach.

Why MCP client identification is hard

Traditional OAuth assumes a client is registered with the authorization server before it starts an authorization flow. That works when you control both sides. It breaks down when an IDE, agent runtime, desktop assistant, or partner tool may discover new MCP servers at runtime.

Dynamic Client Registration was the earlier answer. A client could call a registration endpoint, create a client record, and receive a client_id. That works in theory, but it creates real operational problems:

Many authorization servers do not support Dynamic Client Registration.
Open registration endpoints become unauthenticated write APIs on security infrastructure.
Authorization servers can accumulate unbounded ephemeral client records.
Security teams still have weak attribution for who built or operates the client software.

This is why the MCP ecosystem moved toward CIMD.

CIMD: the new default for dynamic MCP clients

Client ID Metadata Documents invert the registration model. Instead of registering into the authorization server, the client's identity is a URL it controls.

The client_id is an HTTPS URL. The authorization server fetches that URL and receives a JSON metadata document describing the client, including the client name and redirect URIs.

The security model depends on strict validation:

The client_id inside the fetched document must exactly match the URL it was fetched from.
The redirect_uri in the authorization request must appear verbatim in the document's redirect_uris.
If the fetch fails, returns malformed JSON, or fails validation, the authorization server aborts.
Authorization servers must account for SSRF risk because they are fetching a URL supplied during an authorization flow.

CIMD does not magically make every client trustworthy. It does make client identity stable and attributable. A client_id such as https://ide.example.com/oauth-client says something verifiable about who controls that client metadata. A DCR-generated UUID does not.

The MCP precedence order

The 2025-11-25 MCP authorization specification defines the order a compliant client should follow:

Use pre-registered client credentials for the target server if they exist.
Use CIMD if the authorization server advertises client_id_metadata_document_supported.
Use Dynamic Client Registration if a registration_endpoint is advertised.
Fall back to manual entry when none of the above is available.

That order is important for enterprises. Pre-registration remains strongest when you control the client and server relationship. CIMD is the preferred dynamic model when that pre-registration does not exist. DCR is still supported, but it is no longer the preferred default.

What Cross App Access changes

The same specification wave introduced Enterprise-Managed Authorization, often discussed as Cross App Access. Instead of every user clicking through an OAuth redirect and consent screen for each MCP connection, the client can obtain tokens for MCP servers through the enterprise identity provider.

That moves the authorization decision closer to where enterprise security teams need it: the organization's identity system. It is the right direction for enterprise MCP adoption.

It is also not universal yet. As of July 20, 2026, the extension is stable, MCP project materials describe adoption by Anthropic, Microsoft, Okta, and a growing set of MCP servers, and Claude documents beta support for Team and Enterprise plans with Okta at launch. The practical reality is still mixed-client, mixed-server, mixed-IdP support.

What the MCP authentication spec still does not solve

Read the layers carefully and a gap remains.

CIMD identifies client software. OAuth tokens authenticate users and authorize access to a protected resource. Enterprise-Managed Authorization moves token issuance under the enterprise IdP for the connections that support it.

None of those layers gives an enterprise one consistent enforcement point for every MCP request:

Which user, group, agent, and client is behind this request?
Which MCP server is being accessed?
Which tool or action is being called?
Should the request be allowed, denied, rate-limited, or routed for approval?
Where does the audit trail live?

That enforcement plane is a gateway's job. Datawiza Agent Gateway sits in front of MCP servers, binds requests to enterprise identity such as Microsoft Entra ID, Okta, or Ping, and applies tool allowlists, per-user limits, credential protection, and audit trails in one place.

This does not replace the MCP spec. It makes the spec governable in production while the ecosystem continues to converge. The companion post covers the enterprise decision more directly: DCR vs. CIMD for MCP.

Sources reviewed

FAQ

How does authentication work in MCP?

MCP uses OAuth 2.1 concepts. The MCP server acts as a resource server, delegates authorization to an authorization server discovered through Protected Resource Metadata, validates that tokens are intended for that server through resource indicators, and requires PKCE for authorization-code flows. Clients identify themselves through pre-registration, CIMD, DCR, or manual entry in that order.

What is CIMD in MCP?

Client ID Metadata Documents let an OAuth client use an HTTPS URL as its client_id. The authorization server fetches that URL, validates that the document's client_id matches the URL, checks the redirect_uri, and uses the metadata without creating a new client registration record.

Is Dynamic Client Registration deprecated in MCP?

No. DCR is still a supported fallback when the authorization server advertises a registration endpoint. The change is priority: the 2025-11-25 specification prefers pre-registration first, CIMD second, DCR third, and manual entry last.

What is Cross App Access for MCP?

Cross App Access refers to Enterprise-Managed Authorization, where the enterprise IdP can govern token issuance for MCP connections instead of relying only on per-user OAuth consent. It is stable and adoption is growing, but support remains uneven across clients, servers, and identity providers.