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.

- 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.

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.

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.

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!

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.

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.

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...

> look inside

> there's a touch

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?

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.