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