Dynamic Client Registration is deprecated: moving to Client ID Metadata Documents

OAuth 2.0 Dynamic Client Registration is formally deprecated by the MCP 2026-07-28 spec, in favour of Client ID Metadata Documents. It keeps working for backwards compatibility, but it has a date.

If you operate an MCP server with OAuth, this is not urgent. It is still worth understanding now, because it solves a problem you probably already have.

Why DCR was a problem

In the MCP world, a client discovers servers it has never seen. Classic OAuth assumes the opposite: a known client, registered by hand by a human, once.

DCR served as the patch. The client registers itself, on the fly, and receives an identifier. It works, and it produces three unpleasant effects for the server operator.

A table that grows without end. Every installation creates a record. On a public server that becomes thousands of rows, most of which will never be used again.

No identity continuity. The same client, reinstalled, comes back with a new identifier. You cannot recognise it, apply policy to it, or ban it durably.

An abuse surface. An open registration endpoint is an open write endpoint. It has to be rate limited, monitored, and cleaned up after.

What Client ID Metadata Documents change

The idea inverts the problem: instead of the client asking the server for an identifier, it brings one that is already verifiable.

The client identifier becomes a URL, and that URL serves a document describing the client: its name, its redirect URIs, its application type. The authorization server fetches that document instead of creating a record.

What that means for you:

• No registration call to accept, so no open write endpoint
• A stable client identity over time, the same everywhere, that you can log and apply policy to
• Metadata owned by the client and kept current by it, so you no longer host a copy that goes stale

For the exact format and fetching rules, go to the specification rather than an article, this one included. This part of the protocol is still moving.

What still needs validating

Fetching a document from a URL supplied by a third party is an outbound request triggered by untrusted input. The usual precautions apply:

• Accept HTTPS only
• Block internal addresses and the local network, or you have built an SSRF
• Enforce a timeout and a maximum size
• Cache with a sensible duration, and define what happens when the document becomes unreachable
• Verify that the redirect URIs in the document match the ones used in the flow

That last point is the core of the mechanism's security. The rest is HTTP client hygiene.

The transition plan

1. Keep accepting DCR, it remains valid during the deprecation window
2. Add support for Client ID Metadata Documents alongside it
3. Instrument: count how many registrations arrive through each path
4. When DCR's share becomes marginal, announce an end date to your integrators
5. Clean up the dynamic registration table, it will no longer be needed

Step 3 is what keeps this out of gut-feel territory. You do not cut DCR because the spec deprecates it, you cut it when your numbers say it no longer breaks anyone.

FAQ

Do I have to do this now?

No. The feature lifecycle policy guarantees at least twelve months for deprecated features. Handle the transport and the three OAuth changes in 2026-07-28 first.

What if my clients do not host a document?

They stay on DCR during the window. That is exactly why the transition works by accepting both.

Does it change anything for my end users?

Nothing visible. It is plumbing between the client and the authorization server.

You do not want to track these deadlines yourself

Compliance monitoring is €290 a month: I watch the protocol as it moves, tell you what concerns your server, and warn you before it becomes urgent.

Interested? Talk about compliance monitoring →

Related reading

• OAuth for MCP servers: the three changes in 2026-07-28
• Setting up MCP compliance monitoring without a protocol team
• How to migrate an MCP server to the 2026-07-28 spec