Zero-Touch OAuth for MCP

RVuRnvbM2e

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

paulddraper

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

brap

I thought we’re over this collective delusion called MCP

lorecore

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.

maxwellg

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.

ericchiang

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?

sean_lynch

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.

dend

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.

hparadiz

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

flashgordon

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!

russell_h

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

rvz

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.

joeyguerra

I have my chatbot command my chatbot.

zackify

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.

krooj

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.

ai_fry_ur_brain

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

sandeepkd

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.