CIMD vs DCR for MCP OAuth: what's the difference?

Both mechanisms solve the same problem. An MCP client ships before your server exists, the user has no way to hand it a client ID, and the OAuth flow still needs one. The debate about which mechanism to use is usually framed as spec hygiene: DCR is stateful and CIMD is stateless, DCR fills a database and CIMD fills a cache. That framing undersells the change. The difference that matters is who asserts the client's identity. Under DCR the client asserts it and the server prints it. Under CIMD the vendor's domain asserts it. Every governance question an enterprise asks about MCP (which AI applications may reach this server, who connected last Tuesday, how do we cut one of them off) depends on an identity that survives the next install, and only one of the two mechanisms provides that.

Our position is that if you're putting OAuth in front of an MCP server that an organization will ever need to allowlist or audit, you should build CIMD first and keep DCR as a fallback rather than as the plan. Auth0 and WorkOS have both published explainers that cover the mechanics well, and we don't disagree with either. What follows is the argument for why those mechanics change the governance picture, including the places where DCR's defenders are right and the places CIMD does not help.

What is Dynamic Client Registration (DCR)?

DCR is RFC 7591. A client with no prior relationship to an authorization server POSTs its own metadata, including a client name, redirect URIs, and grant types, to a registration endpoint, and receives a client_id (and sometimes a client_secret) it can use immediately. The authorization server stores that record and trusts it from then on.

MCP leaned on DCR because it had no better option. The protocol defined no standard way for a user to supply a client ID for a server the client had never seen, and pre-registration would have required every client vendor to coordinate with every server operator before either shipped. Stripe and Asana added DCR to their OAuth stacks to make their MCP servers self-serve, and our own guide to securing an MCP server with OAuth still describes DCR as the piece most companies have to build before MCP clients can connect. That guide describes what shipped in 2025, and the distance between it and the current specification is a measure of how recently the ground moved.

The same guide carries an operational detail that matters for the comparison. A client that registers through DCR keeps the client_id it was issued for as long as you let it, so a server has to persist every registration it ever minted. Under DCR the registration table is part of your security state.

What is a Client ID Metadata Document (CIMD)?

CIMD turns the direction of trust around. The client_id is an HTTPS URL on the vendor's own domain, and that URL serves a JSON document describing the client. When an authorization server sees a URL-shaped client ID, it fetches the document, checks that the client_id inside matches the URL it was fetched from, checks that the requested redirect URI appears in the document's redirect_uris, and caches the result according to the document's HTTP cache headers. The name on the consent screen and the redirect URIs the server will honor both come from a file that only the vendor can change.

The underlying specification is the OAuth working group's Client ID Metadata Document draft, by Aaron Parecki and Emelia Smith. As of July 2026 it is at revision 02 and is an active Internet-Draft, not an RFC. SEP-991, by Paul Carleton and Aaron Parecki, brought it into MCP, and the 2026-07-28 revision of the MCP authorization specification says clients and authorization servers SHOULD support CIMD, MAY support DCR, and treats DCR as deprecated but retained for backward compatibility. Clients that support every option are told to try pre-registered credentials first, then CIMD, then DCR, and only then prompt the user.

The requirements are short. The client_id must use the https scheme and contain a path component. The document must be valid JSON and carry at least client_id, client_name, and redirect_uris. The authorization server advertises support with client_id_metadata_document_supported: true in its OAuth metadata, so a client can detect it and fall back to DCR when it is absent. SEP-991 recommends caching the document for no more than 24 hours. A complete document for a public client looks like this:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "logo_uri": "https://app.example.com/logo.png",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

One consequence the specification calls out is portability. Because the client ID is a URL the authorization server resolves on demand, the same client ID works against every authorization server that supports CIMD, and nothing has to be re-registered when a server changes which authorization server it trusts. A DCR client ID is bound to the authorization server that issued it.

Isn't DCR good enough?

The case for staying on DCR is better than CIMD advocates usually admit.

DCR is a ratified RFC with more than a decade of implementations behind it. CIMD is a draft that has changed name once already (SEP-991 cites draft-parecki-oauth-client-id-metadata-document-03, before the working group adopted it) and may change again before it is done. Nearly every MCP client that does OAuth already speaks DCR, while CIMD support in clients is still filling in, which is why the MCP specification keeps DCR as the fallback. For a public MCP server whose operator has no intention of restricting which clients connect, the costs of DCR are a registration table and some rate limiting, and neither is a security problem. SEP-991 itself says pre-registration remains the right answer where a relationship already exists, and that open servers may accept any client.

The sharpest version of the objection is that CIMD does not authenticate the client either. A public client with a loopback redirect can be impersonated under CIMD just as it can under DCR: an attacker presents the legitimate vendor's metadata URL, binds the same local port, and collects the authorization code. The server sees the right document and the user sees the right name. If the pitch for CIMD is "verified clients," that pitch is stronger than the mechanism.

All of that is true, and none of it touches the governance question. DCR gives you no stable subject to write a policy about. The question a security team asks, "which AI applications are allowed to connect to this server?", would have to be answered in terms of an identifier that is different on every install, or in terms of a client_name string the client chose for itself. Nobody lets a user type their own name into the SSO screen and trusts what they typed. Agents' client software should not get a different rule. As for impersonation, CIMD names the client software and binds its redirect URIs to a domain. It does not attest which process is running on the laptop, and it does not claim to. Naming is the prerequisite for allowlisting; attestation is a separate problem that neither mechanism solves.

Why does durable client identity matter for enterprise MCP authentication and authorization?

Two groups of people feel the difference, and they describe it in different words.

Platform engineers describe it as tickets that stop arriving. Under CIMD, Claude, Cursor, or ChatGPT can complete OAuth against an organization's MCP server without anyone filing a per-client registration request, because the client's identity is a URL the authorization server already knows how to resolve. The consent screen shows a name that the vendor's domain vouched for rather than a string from an anonymous POST body. The registration table stops growing every time someone reinstalls a client the server has already seen, which in our experience is what most DCR registrations are.

Security and identity teams describe it as questions that get answers. Which clients may hit /authorize becomes a list of URLs. Searching the audit log for everything one client did becomes a search on one identifier instead of a join across every client_id that client ever minted. Revoking a client means removing a URL from the list, and the removal holds on the next install because the next install presents the same URL. These are the operations an access review is made of, and under DCR each of them produces a shrug.

The nearest analogy is why enterprises federate login to an identity provider instead of letting each application keep its own user table: a relying party can only write policy about identities issued by someone it can name. CIMD does for client software what federation does for users, with one limit the analogy should carry. An identity provider authenticates the person. CIMD identifies the software and its redirect URIs, and stops there.

CIMD vs DCR side by side

What does CIMD not fix?

A security review will find each of these.

• Loopback impersonation. Covered above, and SEP-991 states plainly that fully mitigating it is out of scope and that the exposure matches DCR in the same scenario. The specification recommends that servers show extra warnings for clients whose only redirect URIs are on localhost. Platform attestation or short-lived vendor-signed tokens can raise the cost of the attack; they do not remove it.
• Server-side request forgery. The authorization server now fetches a URL that an unknown party chose. SEP-991 lists the mitigations: validate the URL and the IP addresses it resolves to before fetching, cap the response size, time out the request, rate limit outbound fetches, and fetch client metadata only after the user has authenticated. Every one of those is a control that did not exist on a DCR server and has to be built and tested.
• Hosting. A client that used to be a desktop binary now needs a static JSON file on an HTTPS domain. The burden is low, and it is not zero, and it is a dependency on infrastructure the client did not need before.
• Draft status. The IETF document expires in January 2027 unless revised, and it will be revised. Implementations should expect to track changes, and SEP-991 says MCP intends to follow the draft as it evolves while minimizing breakage.
• A third path. MCP authorization now has pre-registration, CIMD, and DCR. SEP-991 names fragmentation as a risk and bets that CIMD is enough simpler for server implementers that it becomes the path most people take. That bet looks right so far, and it is still a bet.

Should you build CIMD or DCR first?

Build CIMD first if the server will ever be used inside an organization that needs to say which clients may connect, or if you're standing up a new authorization server now. The specification says SHOULD, clients that support both will try CIMD before DCR, and the work is a fetch path with SSRF containment plus a cache, not a new database.

Keep DCR running if you already have it and clients depend on it. Deprecated is not removed, and the specification kept DCR for a reason. Turn it off when your own logs show no DCR registrations arriving, not when a blog post tells you to.

Pre-register if the client and server already know each other. SEP-991 is explicit that CIMD targets the no-prior-relationship case and that pre-registration remains the right tool where a relationship exists.

If you run a public MCP server for external developers and have no wish to restrict clients, either mechanism works. CIMD still saves you the registration table and the unauthenticated write endpoint.

The bet is asymmetric. The cost of building CIMD is a bounded amount of server-side work. The cost of not having a durable client identity when a security team asks which AI applications can reach your systems is that you cannot answer, and by then the DCR table has years of anonymous rows in it.

A note on Speakeasy

The Speakeasy AI Control Plane runs an OAuth authorization server in front of the MCP servers it hosts and the third-party servers it proxies, and that server accepts both CIMD and DCR. CIMD support landed in release 1.1.0, so clients that present a URL-shaped client ID, including Claude Code and VS Code, complete the flow without registering first, loopback redirects included. Clients that still speak DCR register the way they always have.

Because the platform sits in the path as the authorization server, the client-identity question above becomes a setting on each issuer rather than a project. An issuer can admit any spec-valid CIMD document, admit a preset of verified clients that Speakeasy maintains along with any document URLs you add yourself, or have CIMD switched off so clients fall back to DCR cleanly. The same setting is readable and writable over the Platform MCP, so an agent can report or change which clients a server accepts. Client metadata documents are cached with revalidation rather than refetched on every authorization. The 1.5.0 and 1.9.0 release notes cover the details.

The default admission mode is open, and we made that explicit in release 1.18.0 rather than leaving it as an internal state nothing displayed. Turning an allowlist on by default would have stopped clients that authenticate today, so enforcement is something an operator opts into. An issuer nobody has configured isn't allowlisting anything, and a team that wants the CISO's answer has to go and choose it. For how client identity fits with the rest of agent governance, the MCP gateway and AI Control Plane guides carry the wider argument.

If you're deciding whether to own an authorization server for your MCP servers, or you've inherited a DCR table you'd rather not, we'd like to hear how you're approaching it. Talk to our team.