Announcing CIMD Support for MCP

PropelAuth's MCP Authentication now supports Client ID Metadata Documents (CIMD), the client registration method the current MCP authorization spec recommends.

With CIMD, an AI client identifies itself with a URL it hosts instead of registering with your authorization server first. For you, that means once you turn it on, any CIMD-capable client can connect to your MCP server without an entry in Allowed MCP Clients, and Dynamic Client Registration (DCR) becomes something you keep enabled only if a specific client still needs it.

What Problem Does CIMD Solve?#

OAuth was designed for a world where a client and an authorization server know each other in advance. Someone registers the app, gets a client_id, and the server stores the app's name and allowed redirect URIs. That works when you have a handful of integrations. It falls apart with MCP, where a user might connect any of dozens of AI clients to your server, and neither side has met the other before.

The first answer to this was Dynamic Client Registration (RFC 7591): the client calls a registration endpoint and asks for credentials on the spot. It works, but it means any client that can reach your registration endpoint can create a record in your authorization server, and the server has no way to verify that the request came from the client it claims to be. That's why the current MCP authorization spec deprecates DCR in favor of CIMD.

How Client ID Metadata Documents Work#

With CIMD, the client_id is a URL. The client hosts a small JSON document at an HTTPS address it controls, and that address becomes its identity:

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

When an authorize request arrives with a URL-shaped client_id, PropelAuth fetches that document, checks that the client_id inside matches the URL exactly, and validates that the redirect_uri in the request appears in the document's redirect_uris. If everything lines up, your user sees a consent screen that names the client, and the flow continues like any other OAuth 2.1 authorization code flow with PKCE.

Two consequences for you:

• No more redirect URI allowlisting for these clients. The client's own metadata document is the allowlist, so CIMD clients don't need an entry in Allowed MCP Clients.
• The client's identity is tied to a URL it controls. Instead of taking a registration request at its word, PropelAuth reads the metadata from a location only that client can publish to. That doesn't make every CIMD client trustworthy, but impersonating one is a lot harder than filling in a DCR form.

PropelAuth advertises support through client_id_metadata_document_supported: true in its authorization server metadata, so spec-following clients discover it automatically and prefer it over DCR.

How CIMD Fits With Your Other MCP Clients#

Nothing about your existing setup breaks. CIMD sits alongside the two other ways to create an MCP OAuth client:

Our recommendation: turn CIMD on, keep manual clients where you want them, and treat DCR as a compatibility fallback. Enable DCR only for a client that needs it, and plan to turn it off once that client catches up.

Enabling CIMD in PropelAuth#

1. Open the MCP page in the PropelAuth Dashboard. If you haven't enabled MCP Authentication yet, do that first and pick the environments you want it on for.
2. Under How Do Users Create OAuth Clients, turn on Client ID Metadata Document.
3. That's it for CIMD clients. Scopes, session duration, and token validation through the Introspection API all work the same way they do for every other MCP client.

Client creation events for CIMD clients show up in the MCP Audit Log like any other client, so you can see which tools your users are connecting.

Full setup details, including scopes and the framework examples, are in the MCP Authentication docs.

Why We Think This Is the Right Default#

DCR got MCP off the ground. You could paste an MCP server URL into Claude Desktop and be logged in thirty seconds later, with nobody on either side filling out a form. The cost was that a registration request carried no proof of who sent it, so there was no good way to tell a real client from something pretending to be one.

CIMD keeps the thirty-second experience and fixes the trust problem, which is the kind of trade we like. As with Default Resource, we want the spec-compliant path to be a single toggle away, with older options available for exactly as long as real clients need them.