Comment by programmancer
16 hours ago
I am currently trying to use Microsoft Entra ID auth for an MCP server I'm implementing, and I genuinely feel like I must be an idiot.
- I can use the `WWW-Authenticate` header to indicate a resource metadata URL for the client.
- I can use this to indicate an authorization server (Microsoft Entra) and a scope (for the app registration that handle which app roles each user is given to differentiate different capabilities for different users).
- I can NOT indicate a client_id, because that's just something that each client (agent) makes up on its own?
- To initiate a login on the .../authorize URL in Microsoft Entra, you need to pass a known client_id that matches an app registration in Microsoft Entra. Whatever the client makes up will surely not match anything in Microsoft Entra.
- I COULD in theory support dynamic client registration, but of course Microsoft Entra doesn't.
Is it even possible to make this work out of the box? The only way forward I can see is implementing my own dynamic client registration shim in front of Microsoft Entra that just returns the same static client_id to everyone, which matches an actual client_id in Microsoft Entra.
But surely this protocol actually works today for real Enterprises without workarounds? It feels like I must be missing something obvious.
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
[flagged]
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...
Depending on the setup, you just have to be really careful to avoid confused deputy scenarios.
I wrote about it: https://den.dev/blog/mcp-confused-deputy-api-management/
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.
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]