MCP Authentication Reimagined: From DCR Dynamic Registration to CIMD Linking

The Core Challenge of MCP Authentication: How Do Strangers Log In?

As AI Agents become more widespread, an unavoidable question emerges: Agents need to act on behalf of users, which means users must be able to authenticate through an MCP client to an MCP server. The standard approach to authentication is OAuth or OpenID Connect.

The problem is that both OAuth and OpenID Connect are built on a fundamental assumption — that the two parties have "met before." They assume the MCP client has already been registered with the server or authorization server. But you can't pre-register a client you've never seen or interacted with. Before any access token can be issued, the two parties must first complete a "handshake."

This handshake works roughly as follows: the MCP client sends a request without an access token, the server returns 401; service discovery follows to confirm the authorization server configured for this MCP server; then the client needs a client ID to proceed through the full OAuth flow and ultimately obtain an access token. How to obtain this client ID is precisely what this article — and what Auth0 Principal Developer Advocate Sam Welland explores in his talk — is all about.

OAuth 2.1 is a streamlined and hardened version of OAuth 2.0, removing flows considered insecure (such as the Implicit Grant) and mandating the use of PKCE (Proof Key for Code Exchange) to prevent authorization code interception attacks. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0, introducing the ID Token (typically in JWT format) to prove user identity to the client. The core assumption of both is that the client has already registered with the authorization server and obtained a stable client_id before initiating an authorization request — not a problem for traditional web applications, but in the MCP context, the client might be a plugin the user just installed or a dynamically generated Agent, with no opportunity for "pre-registration" at all.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic to standardize interactions between AI assistants and external tools and data sources, enabling Agents to call file systems, databases, APIs, and other resources through a standardized interface. It is precisely because of this "one-time, on-the-fly connection" characteristic between MCP clients and servers that the traditional OAuth registration assumption creates a fundamental contradiction in this context.

DCR Dynamic Client Registration: It Works, But Not Well Enough

The first traditional approach for obtaining a client ID is DCR (Dynamic Client Registration), defined in RFC 7591. The logic is: whenever an MCP client needs to connect to a server that requires authentication, it makes a POST request on the fly to the authorization server's registration endpoint. The authorization server immediately creates a brand new client application, returns a client ID and client secret, and permanently stores these credentials in its database until someone manually deletes them.

With these credentials in hand, the client can complete the OAuth 2.1 flow: obtain an authorization code, exchange it for access tokens, refresh tokens, and ID tokens, and use these to make authenticated requests to the MCP server. The entire process requires just one registration request to obtain all the attributes needed for authentication.

But DCR has several serious flaws when used in the MCP context:

• Client ID sprawl: Every registration creates a new record, a new client ID and secret in the authorization server. When large numbers of MCP clients register repeatedly, this number quickly spirals out of control.
• Lack of verification: Registration endpoints are typically open to anyone. Any client — whether new, frequently used, or something you threw together over a weekend — can register, with no way to determine whether it's trustworthy.
• Key management burden: Each server produces secrets that need to be stored, rotated, and revoked. At scale, this becomes an operational nightmare.
• Scenario mismatch: The DCR spec wasn't designed for MCP. It's better suited for stable applications that "register once and live long." MCP clients, by contrast, often exist for only minutes to hours and are discarded after use.

In short, DCR works, but it's not the optimal solution for MCP.

In the DCR flow defined by RFC 7591, the client submits a JSON request body to the authorization server's registration endpoint containing metadata such as redirect_uris, client_name, and token_endpoint_auth_method, and the server returns a client_id and optional client_secret. This mechanism was originally designed to let third-party applications self-onboard onto multi-tenant SaaS platforms or open ecosystems — not to handle high-frequency, short-lived ephemeral clients. Its companion spec, RFC 7592, defines a client registration management protocol allowing subsequent updates and deletions of registered clients — but in the MCP context, these lifecycle management operations are almost never performed, leaving only an ever-growing pile of "zombie records" in the database.

CIMD Client ID Metadata Documents: Let the URL Be the Identity

The next-generation approach is CIMD (Client ID Metadata Documents). Its core idea is genuinely disruptive — what if the client ID itself were the client?

Here's how it works: the client actively "publishes" itself, exposing a client.json (or any JSON file) for the MCP authorization server to fetch and inspect. This document contains the key information needed for the authorization flow: client ID, redirect URIs, token endpoint method, and so on.

The most critical difference is that the client ID is no longer a randomly generated string — it's the HTTPS URL of this JSON document itself. The server can directly access this URL, fetch it, and verify its contents. Once the server confirms that the URL pointed to by the client ID is valid, it has all the information it needs to issue an access token.

This means the registration step is eliminated entirely — nothing is stored. This perfectly aligns with the latest MCP specification's goal of statelessness: the authorization server no longer needs to store client IDs and secrets.

How CIMD Ensures Security

Without registration and key storage, security is maintained through a few rules:

• HTTPS URL with path: The client ID must be a precise HTTPS URL pointing to the metadata document, with no shared secrets involved.
• Defensive fetching: The server fetches the client ID and metadata document only when needed, verifying it and using only the required fields.
• Hostname as consent page: When a user first logs in or connects to an MCP server, the consent (authorization) page displays which hostname is requesting which scopes.
• Verifiable redirect URIs: Redirect URIs are part of the metadata document, allowing the server to validate where the user is sent back to after successful authentication.

The trust anchor that CIMD relies on is the PKI system underlying HTTPS itself — any party holding an HTTPS endpoint under a domain name has already had their domain control verified by a CA. This aligns with the thinking behind WebFinger, Solid Protocol, and other decentralized identity approaches: using domain ownership in place of a centralized registry. It's worth noting that CIMD does not provide guarantees about client code integrity — it can only prove "this request comes from the owner of this domain," but cannot verify whether the code running on the client has been tampered with. For high-security scenarios, additional software supply chain verification measures are still needed. Additionally, once the content of the client.json document is cached, update propagation will be delayed, so authorization servers need to set sensible fetch caching policies to balance performance and freshness.

The Value of Linking: Domain Name as a Trust Signal

Replacing "registration" with "linking" brings several tangible benefits:

URL as identity — no more randomly generated values; the client ID is simply that precise metadata document URL. Domain name becomes a genuine signal of the caller — you can determine client ownership based on domain ownership, and can even directly blacklist low-reputation URLs. Inherently stateless — nothing to store, nothing to rotate; the server simply reads the metadata document and uses the values in it, a perfect fit for MCP. Zero-configuration onboarding — no residual traces left behind.

DCR vs CIMD: How to Choose

Comparing the two side by side, the differences are immediately clear:

Dimension	DCR	CIMD
ID generation	Created at runtime on the authorization server	Client pre-exposes a document URL
Identity proof	None (typically an open endpoint)	Domain ownership serves as proof
Server state	Stores client ID, secret, etc.	Stateless, stores nothing
Best use case	Long-lived clients	Short-lived ephemeral Agents, MCP clients and servers

It's worth emphasizing the language used in the MCP specification: you may use DCR in MCP, but should use CIMD where possible.

In the live demo portion of the talk, Sam used MCP Inspector to connect to the same local MCP server via two different paths. The first time, using DCR: Inspector accessed the .well-known protected resource document, automatically completed registration after discovering the authorization server address, the auth mechanism showed DCR, and a new application was created on the authorization server. The second time, after clearing the auth settings and switching to CIMD: instead of registering, it provided a URL pointing to client.json as the client ID, and the auth mechanism showed CIMD. The key difference — when repeatedly disconnecting and reconnecting, DCR creates new applications on the authorization server again and again, while CIMD always reuses the same application.

Conclusion: A Trend, But Not a Silver Bullet

CIMD is not magic. It's currently an IETF draft, in a "nearly complete" stage. It proves client origin through the domain name in the URL, and preserves the possibility of implementing confidential clients without shared secrets — though enterprise governance scenarios will differ, which is a separate topic.

The complete picture is: MCP adopts OAuth 2.1 (the evolved version of OAuth 2) paired with CIMD, optionally combined with on-behalf-of token exchange and resource indicators. For the vast majority of MCP clients — especially MCP servers and ephemeral Agents — CIMD is the better choice; DCR continues to serve long-lived hosted clients where "the registration record is a feature, not a burden."

For developers currently using DCR, now may be the time to evaluate migrating to CIMD — as the talk's tagline puts it: Stop registering, Start linking.

Token Exchange (RFC 8693) is another important piece of the CIMD ecosystem: when an MCP server needs to call a downstream API on behalf of a user, it can exchange the user's access token for a new token specifically scoped for the downstream service, enabling a delegation chain without requiring the user to authorize each downstream service individually. Resource Indicators (RFC 8707) allow clients to declare the URI of the target resource server in authorization requests, enabling the authorization server to issue audience-restricted tokens that prevent tokens from being used for unintended services — a critical mechanism for preventing token confusion attacks in scenarios where an Agent may simultaneously call multiple MCP servers. These two RFCs, together with OAuth 2.1 and CIMD, form the complete technical stack for MCP secure authorization.