Zero-Touch OAuth for MCP

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.

Before you get too far into the usual “MCP is dead, Skills forever” debate

The real valuable capability MCP offers over skills/CLI is isolating the auth flow outside of the agent’s context window, and potentially out of the harness completely. This is valuable from a security perspective obviously. It’s also just a much easier user experience for normies and large businesses adopting AI tools. I hear all the context bloat and tool call redundancy complaints. But this structure for handling auth has real value.

Maybe the idealized form of MCP is just an auth gateway for the API and nothing else. That’d still be a win.

Huge congrats to the folks behind this at Okta, A\, Microsoft, Figma, Linear, etc...

For the MCP nay-sayers - don't worry there's something here for you too :)

This is powered by a new token format called an ID-JAG - https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... - and isn't MCP specific at all. ID-JAGs can be used for safe and secure data sharing anywhere where data is shared between applications that use the same SSO provider.

Read it multiple times, its definitely useful, centralizes the audit and access in one place (with IDP). The IDP can very well act as a proxy API gateway taking care of token exchange when required instead of putting the onus on Client. Thats another approach which has been adopted by some other players in this domain.

On a personal level, what I felt bit uncomfortable with is this idea of access being delegated on my behalf by IDP to client without making me aware about it. May be I am too used to the concept of user presence in the flows that happens on browser. This it evolving more towards centralizing the access for the machines.

Given in the enterprise environment the identity really belongs to the company instead of individual, its probably acceptable.

How its gets incorporated in customer identity is altogether a different challenge. Its probably not possible to have this kind of trust between IDP, client and the resource authorization server.

This is fantastic. Ive been so fortunate to work with the mcp folks last few months on a couple of the SEPs (and my own experimental sdk in go). I used to be a naysayer. "Its just apis" I used to say. "Sheesh the invented another abstraction" I used to say.

What folks dont realize is it is the "P" in MCP that throws people off. When you build a traditional app you have to build forms, ui, req/response handling, bidirectional channels, long running tasks, auth and so on.

With mcp 80% of this common layer is taken care for you. So mcp is really an "app framework" than a protocol (well there is that too).

Unified auth is a huuuge boost. Can't wait to see more cool things!

If only they would support the web and let you just issue a long running cookie....

I hacked the spec to pass through a cookie via the oauth handshake to do this without needing an oauth server.

Its really dumb they don't want to allow this.

If no cookie, open webpage.

If cookie set, close and persist.

I literally wrote an 80 page mini book on MCP yet it frustrates me to no end.

Oh wow - seeing my own work in the wild is ... wild. I implemented the RAS end of this for Atlassian. There will certainly be iterations around this flow - CIMD, better tenancy support, etc., but all the folks involved in delivering this at Anthropic, Okta, and here at Atlassian were fantastic.

Hey folks - I am one of the folks at Anthropic that helped deliver this in partnership with Okta and a handful of MCP partners. We're very excited about this taking shape in Claude (in addition to the MCP spec, of course, where EMA is now a stable extension) and are looking to expand adoption to other identity providers and clients as well.

If you have any feedback, feel free to drop it in here! Always happy to hear about folks' experience and how we can make it better.

I don't quite understand the advantage of this over regular oauth. I think I need an example comparison of the authz flows.

MCP auth has been a huge pain point for us at C1 - both for our own internal MCP use and in our in-product MCP Gateway - so very glad to see this landing.

We launched support today for C1 to act as an EMA identity provider (we mint the short-lived scoped tokens), so I'm excited to hook this up for Linear and some of the other MCPs we use, and get out of the business of constant OAuth flows. Claude has been doing this magically for some of their built-in connectors (at least Slack I think) and the experience is pretty great.

Disclosure: VPE at C1. We wrote up how we’re approaching it here if anyone’s in the weeds on this: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

Wait this is awesome. A huge issue with Enterprise OAuth2.0 is managing all the random apps. Each with their own half-baked enterprise controls for managing scopes, token expiry, and no control over device bound sessions.

So instead, you can run centralized infra to validate a user, device, what scopes their requesting and duration, and enforce policies for all your apps?

Can we get this in other OAuth 2.0 clients?

Need this for CLI tools like gcloud, knife, npm, etc. Maybe an Okta based JWT.

Auth has been a wild journey in MCP. It really is a valuable differentiator to things like Skills for enterprises though. Congrats to the team on the ship.

I have my chatbot command my chatbot.

This actually looks like a far better use-case for MCPs than the previous per-user per server MCP design which that was completely rushed and made no sense.

You can tell with this Anthropic consulted with experts first on the design and implementation of this rather than vibe coding the spec in isolation. Unless the user themselves is compromised and connects via the Enterprise-Managed Authorization, at least you can remotely revoke permissions / access to reduce that risk.

We'll see, but give credit where credit is due.

"Watson you have a blazing talent for observing the obvious" - Sherlock Homes

Why does my text autocomplete cli need an ability to sign into things?

[dead]

[flagged]

I thought we’re over this collective delusion called MCP