I don't think you are missing anything obvious. Entra ID doesn't support DCR, and the state of the ecosystem here is suboptimal.

The typical way to do MCP OAuth is with traditional up-front registered clients. However, in practice a lot of MCP clients work with an assumption that DCR works, and as you point out don't offer an option to specify a client ID.

However, some clients do support that (ad: our tool Erato does[0]), and the typical solutions deployed in enterprises do, where MCP access is usually centralized via a web UI like ours. One alternative that also exists is are MCP gateways, which do pre-registred oauth between the gateway and service, and allow for DCR between the gateway and clients.

[0]: https://erato.chat/docs

I actually implemented this yesterday. The gist is this library runs the MCP server: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...

Then I build an authbroker application using openid to handle client registration and build the jwt. End result is something that can determine tool availability and permission using an employees department, or other criteria.

So yeah the dynamic client registration is needed.

We had the same issue with the client_id and for security reason we weren't willing to enable DCR.

What we ended up doing, was the app proxying the OAuth flow, to inject a hardcoded client_id. So we lie to the MCP client telling it we support DCR while behind the hood we use a standalone client_id as usual for the MCP.

If you want to take example at it https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...

Yeah, I recently documented how to use pre-registered clients with FusionAuth[0] (my employer). DCR's newer, better sibling CIMD is on our radar and under active discussion[1], but not currently available.

An alternative to the proxy you suggest is to generate a new Entra client id (with PKCE enabled) for every MCP client in a developer portal or similar, then have the user configure their client with that client id. Here's the CLI command I found to do this[2], but I bet there's an API too. Here are config instructions for Claude Code[3] and ChatGPT[4].

Client pre-registration is acceptable, but not optimal, for developers, and is a first class citizen in the spec[5]. If your main audience is internal and you can expect them to follow configuration instructions to get access to the MCP server, this approach can work.

But it's definitely not acceptable for widespread, public integrations if your audience is not developers. That is where a lot of the power and opportunity for MCP lies.

0: https://fusionauth.io/docs/extend/examples/controlling-acces...

1: https://github.com/FusionAuth/fusionauth-issues/issues/3230

2: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...

3: https://code.claude.com/docs/en/mcp

4: https://developers.openai.com/api/docs/guides/developer-mode

5: https://modelcontextprotocol.io/specification/2025-11-25/bas...

[flagged]

[flagged]

[dead]