Identity

DCR is deprecated. Your identity provider was right

Your IdP won't do open Dynamic Client Registration and your MCP client says it must. The spec has moved your way. Four routes, and what each one costs.

By Edwin Ashdown7 minute read

In this post 6 sections
  1. The spec moved to your side
  2. Your identity provider is not unusual
  3. Four routes, and what each one costs
  4. Check three fields this week
  5. The gateway, done properly
  6. Sources

You were asked to roll out MCP servers. You pointed a client at one behind your company’s identity provider and got this: “Incompatible auth server: does not support dynamic client registration”. Then you asked the identity team to turn on Dynamic Client Registration and they said no.

They were right. I spent last week reading every revision of the MCP authorisation spec, six identity providers’ documentation, and the GitHub issues where people hit this wall. The spec has come round to your identity team’s position. The hard part now is getting your clients and your identity provider onto a route they both support.

The spec moved to your side

In March 2025 the MCP authorisation spec said implementations “SHOULD support” OAuth Dynamic Client Registration (RFC 7591), the mechanism that lets any client register itself with an authorisation server without asking anyone. That suited a world where every MCP server ran its own authorisation server.

In June 2025 the MCP server became an OAuth resource server, which meant your enterprise identity provider could be the authorisation server. That is when this landed on identity teams.

In November 2025 DCR dropped to MAY, kept “for backwards compatibility”. Client ID Metadata Documents, an IETF draft where the client’s ID is a URL to its own published metadata, became the recommended mechanism. Pre-registration got its own section and went to the top of the order clients should try.

The current revision, dated 28 July 2026, says it plainly: “Dynamic Client Registration is deprecated. New implementations should use Client ID Metadata Documents instead.” The earliest it can be removed is the first revision on or after 28 July 2027.

If your identity provider doesn’t offer open DCR, you are not off-spec. You are on the spec’s preferred path. The clients and servers built in 2025 that assumed DCR are the ones behind.

Your identity provider is not unusual

None of the six identity providers I checked offers open DCR out of the box.

Microsoft says in writing that “Microsoft Entra ID doesn’t publish an RFC 7591 registration endpoint”, and its discovery document has no registration endpoint. Google’s has none either. Okta’s registration endpoint expects a caller that already holds credentials, which a client arriving cold does not have. Auth0 disables DCR by default and warns that if you turn it on, “anyone will be able to create applications in your tenant without a token”. Keycloak ships with no trusted hosts, so “anonymous client registration is de-facto disabled”. Ping says DCR “can expose your server to unwanted client registrations”.

That caution has a basis. RFC 7591 itself says client metadata is self-asserted and that a rogue client can borrow a legitimate client’s name and logo. Obsidian Security found Square’s MCP server accepting registrations without restricting redirect URIs, so an attacker could register their own client and take over a merchant’s account from one link. In Obsidian’s testing, only 27 of 660 authorisation server endpoints (4 per cent) supported DCR at all.

The pain is real on the client side too. The Claude Code issue for GitHub’s remote MCP server, which has no DCR, has been open since July 2025 with 142 thumbs up.

Four routes, and what each one costs

There are four workable routes. Each one moves the cost somewhere, and the right choice depends on two things: your identity provider, and the clients your people actually use.

Route Works with Clients that support it today What it costs you
Pre-registration Any IdP, including Entra and Google Claude Code, Claude custom connectors, VS Code, Cursor, mcp-remote One app registration per client, every redirect URI by hand, and the buggiest client path
Client ID Metadata Documents Auth0 (admin imports each URL), Keycloak (experimental); not Entra or Google Claude, Claude Code, VS Code, mcp-remote Your authorisation server fetches URLs it is given; trust becomes a domain allow-list
A gateway in front of your IdP Any IdP All of them You run a token issuer, or you collapse every client into one identity
Enterprise-managed authorisation Okta only, in early access Claude, Claude Code, Cowork; VS Code in preview Registration moves to the IdP admin; it doesn’t disappear

Pre-registration is what Microsoft does for its own enterprise MCP server: third-party agents “require a custom client Id” registered in your tenant. It keeps your identity provider as the only authority. The cost is maintenance. One engineer described keeping every client’s redirect URI current in Entra as “ongoing whack-a-mole as clients and versions change”, and at least one major client shipped static client ID support this year, then regressed it.

Client ID Metadata Documents are where the spec wants everyone to end up. There is no registration database, and an enterprise can allow-list the client domains it trusts, which open DCR never offered. The catch is support. Entra and Google don’t have it, so for many readers this route isn’t available yet. The spec also notes the authorisation server must guard against being tricked into fetching internal URLs.

A gateway comes in two shapes, and the difference matters. The cheap one answers every registration request with the same pre-registered client ID. It works with every client, and your identity provider can no longer tell one client from another. The spec says proxies that do this “MUST obtain user consent for each dynamically registered client”, and Obsidian’s account takeover findings are this pattern going wrong. The heavier shape is a gateway that is itself the authorisation server, issuing its own tokens bound to each MCP server and signing users in through your identity provider with one registered client. That works with any client and any identity provider today, and you now operate a token issuer that has to be secured and audited.

Enterprise-managed authorisation uses an IETF draft grant, often called Cross App Access, where your identity provider issues the token for a named MCP server after the user signs in. No consent screens, and policy sits with your identity admins. It became a stable MCP extension in June. Today only Okta issues the grant, labelled early access, so it is the right answer for few organisations this month.

The route to avoid is the one many teams take by default: static API keys in headers. Astrix found 53 per cent of the open-source MCP servers it examined relied on static keys or tokens, and 8.5 per cent used OAuth. I’ve written about the raw token problem in MCP servers before.

Check three fields this week

You don’t need to buy anything to work out which route is open to you.

Fetch your identity provider’s discovery document. For Entra that is https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration; for most others it’s the issuer URL plus /.well-known/openid-configuration or /.well-known/oauth-authorization-server. Look for three fields:

  1. registration_endpoint. If it’s missing, DCR is not an option, which is fine.
  2. client_id_metadata_document_supported. If it’s true, Client ID Metadata Documents are open to you.
  3. code_challenge_methods_supported. The November 2025 spec tells clients to refuse to proceed if PKCE support isn’t advertised. Entra’s common endpoint doesn’t list this field, so check what your clients do with that before you commit.

Then list the MCP clients your people use and match each one to a route in the table. If the clients you care about and your identity provider share a route, take it. If they don’t, you are choosing between registering every client by hand and putting a gateway in front.

The gateway, done properly

If you end up at the gateway, make it the heavier shape. Each client keeps its own identity, tokens are scoped to one server, and the gateway records who did what.

That is the position I built AgentValet to sit in. Each agent gets its own identity and only the access it has been granted, risky actions wait for a person, and every call is on the record. The MCP broker is open source if you want to read how it works. The MCP page shows how it sits between your clients and your servers. For the identity side of this, authentication versus authorisation for agents is the background.

Sources

Filed under

  • mcp
  • oauth
  • credentials
  • identity

Give your agent only the access it needs

Grant each agent a narrow set of actions, hold the risky ones for your approval, and keep a signed record of every call.

Protect my first agentWatch your agent’s calls live, no signup
All posts

Identity

Your client clicked Allow. You are still holding their keys

Agencies think OAuth got them out of custody of client credentials. The 2025 and 2026 integrator breaches say otherwise. A custody checklist.

7 min read