8 ms·

Zero-Touch OAuth for MCP

278 points by niyikiza 3mo ago

Jimmy0252 3mo ago
[flagged]
- idoma 3mo ago
  thank you mr. LLM
  - takethebus 3mo ago
    my account is too new I can't flag them :/
paulddraper 3mo ago
"Watson you have a blazing talent for observing the obvious" - Sherlock Homes
RVuRnvbM2e 3mo ago
I don't quite understand the advantage of this over regular oauth. I think I need an example comparison of the authz flows.
- maxwellg 3mo ago
  In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department. Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem. There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...
  - amluto 3mo ago
    This is bonkers. Sure, if I’m a business, I will make a business decision to share, or not share, some resource with ChatGPT. But, if I do decide to share something with ChatGPT, I absolutely do NOT want it shared with every single ChatGPT thread, more or less how I don’t want it shared with every single tab an employee has open in a browser.
    - qt31415926 3mo ago
      Isn't that what's solved by this method? Your SSO provider (e.g. Okta) is now what gates each employee's resource access for different MCP resources.
      - amluto 3mo ago
        I don't think so. The article is all about reducing friction. Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps "Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such." That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted! Now I realize it's silly for the prompt to look like "Would you like to grant [OpenAI/Anthropic/whatever] access to such-and-such account with such-and-such OAuth resources?", but having some kind of explicit opt-in, per conversation, to MCP access seems really quite important. But the article all about reducing friction and avoiding prompts. So maybe LLM providers will do a good job, but I'm not holding my breath.
        iugtmkbdfil834 3mo ago
        << The article is all about reducing friction. I read the initial paragraph from the page and I had similar reaction with an additional touch of: 'There is a purpose for that friction.'
        deleted 3mo ago
        [deleted]
        3mo ago
- megous 3mo ago
  Advantage is user has no control/is not needed to consent about what apps they're authorizing to share their information between each other, bacause the decision to delegate access is at the IdP policy level. User many never know which apps/services were authorized to share their information. Wait, is that an advantage? ;-)
  - sandeepkd 3mo ago
    For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.
    - yammosk 3mo ago
      As someone who has been creating agentic workarounds at my large employer and in a lot of conversations with security as a result, this does not seem to be a huge advantage from the company side. They are very much invested in users being aware of what they permit. The company does want the final say either with shutting down a compromised user or blocking one service from agents and allowing the other, but they 100% do still want employees to be actively engaged and applying their own consent. Removing that from the employee also removes the employee from responsibility for any breach of information IMO, and companies definitely don't want that lol. What they do want is users to stop complaining about the annoying reauth every 8-12 hours for a dozen services which this does. The kinds of wishlists I hear are more about users managing fine-grain service permissions for various agentic roles and managing which agents have access to which role, which leans the other direction. They want to allow users are to treat agents like cloud services and have a greater responsibility for applying least privilege, justify leak risks, etc. The onus to protect this data will always be an employee responsibility in the end.
      - sandeepkd 3mo ago
        I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle. What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.
brap 3mo ago
I thought we’re over this collective delusion called MCP
- isubkhankulov 3mo ago
  MCP is just an API designed to be token frugal
  - NamlchakKhandro 3mo ago
    Frugal is definitely not a word i would use in the same sentence as mcp
    - connor4312 3mo ago
      It's as frugal as your harness makes it. It's just a bunch of tools and a description of how to use them. Most mature harnesses do some kind of tool search and/or progressive disclosure. Many harnesses have some smarts to page out overwhelming results to a file so a model can grep/jq them easily. Some harnesses expose tool schema to models so their results can be directly transformed or even chained in [code mode](https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/).
- mikestorrent 3mo ago
  I thought we were all smarter than directly giving agents access to all of our long lived tokens
- stackedinserter 3mo ago
  Why is it delusion? What are better ways to make LLM talk to other services?
lorecore 3mo ago
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.
- dend 3mo ago
  We're always looking at making it a smoother experience - it's a top pain point for developers and IT admins alike. If you have feedback - feel free to send it my way!
maxwellg 3mo ago
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-assertion-authz-grant/ 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.
- asdfsa32 3mo ago
  Software and quality of life is worst because of these companies. So congrats to them indeed.
ericchiang 3mo ago
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?
- dend 3mo ago
  The standard itself is not MCP-specific. As long as the client and the server adopt ID-JAG, they're golden. RFC draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
sean_lynch 3mo ago
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.
- brookst 3mo ago
  I agree that having auth outside of context window is good. But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don’t know the server’s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it’s API, or its domain can use it intelligently. I used to think MCP was dumb. I’ve written to large MCP servers, one for CAD and one for music, and I am a complete convert.
- Ferret7446 3mo ago
  > The real valuable capability MCP offers over skills/CLI is The real lesson is that MCP vs skills is not a binary. They are simply different tools. Each may or may not be better given different requirements. Which is better, a knife or a saw?
  - fnordpiglet 3mo ago
    There’s even a skills over MCP WG; and I typically deliver skills via tools in my MCPs intentionally. I find Claude and codex recall of skills via MCP tools to actually be higher than skills themselves, which I feel have an (unmeasured) less than 30% recall rate. I have to typically force skills to be loaded explicitly through / or $ depending on the flavor and skill graphs are very unreliable.
- imazhar101 3mo ago
  [flagged]
dend 3mo ago
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.
- mikestorrent 3mo ago
  Fantastic news. Is there any communication between you folks and the Microsoft Entra (Azure AD) team? Would love to know if we can expect this soon or if will take a while.
  - dend 3mo ago
    We are in touch with the Microsoft Entra ID folks to see how we can better integrate EMA in their stack!
    - 9dev 3mo ago
      While you're at it, bug them a bit to finally add support for MCP servers in Copilot. I'm on an Odyssey to find a way for our customers to use our MCP within their Copilot environment…
    - mikestorrent 3mo ago
      Fantastic, appreciated.
- brianjking 3mo ago
  Great work, thank you for doing this. Just so I understand, this isn't yet available yet, right? Still in SEP stage?
  - dend 3mo ago
    It is available! The feature is available in Claude, with Okta being the first IdP to support it (hopefully more coming soon) and with a bunch of MCP partners launching with us today. The underlying extension has been in the MCP protocol for some time and is now officially stable.
hparadiz 3mo ago
Need this for CLI tools like gcloud, knife, npm, etc. Maybe an Okta based JWT.
- dend 3mo ago
  What's interesting about this standard is that it's not really MCP-specific. It can work just as nicely for any other workload - it just requires the authorization server/IdP to support it and the receiver to know how to handle the trust relationship.
flashgordon 3mo ago
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 3mo ago
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-authorization/overview https://www.c1.ai/docs/product/admin/enterprise-managed-auth...
- dend 3mo ago
  Love more adoption of EMA and, of course, better infra for MCP developers. Thanks for such a quick turnaround on this feature work!
rvz 3mo ago
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.
- dend 3mo ago
  FWIW, we never vibe-coded the spec to begin with, but yes - auth is a continuous learning process, and we're lucky to collaborate with some really talented folks both inside and outside the company (e.g., this launch we worked closely with Okta to see how we can best wire things up) to make this a smoother experience. Keep the feedback coming!
joeyguerra 3mo ago
I have my chatbot command my chatbot.
zackify 3mo ago
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.
- dend 3mo ago
  Hey - one of the lead maintainers of the MCP project here. There are a lot of scenarios where this simply won't scale (both from a usability and security standpoint). Cookies were made for the browser. MCP servers and clients often operate in environments where that is not a guarantee.
  - deleted 3mo ago
    [deleted]
  - SkyPuncher 3mo ago
    I've been working on an MCP for creating semi-deterministic flows in Claude code (essentially skills, but broken down into pieces). In order to track execution and state, I have the LLM pass the MCP a unique "execution id" with every call. This lets me programmatically step it through skills and know exactly where execution progress is. I've been considering a similar approach for the web. Essentially, do a short-lived, one-time use token exchange for every single call back and forth. * LLM: "I'd like to interact with your site" * Site: "Great, here's first token. I will exchange it for a new one on the next call. Do not share with with another site. You can authenticate in your browser with this link: [example.com]" * Then you can go back and forth. It'd be rather annoying to auth in the browser every time, but it would enable a low-touch flow. Long term, it'd be ideal to have some sort of out-of-band credential store/tool available, but this would start proving the concept out. Don't use it for highly sensitive stuff, but it would enable a lot of agentic flows that are currently blocked by high-lift MCP setup.
  - freakynit 3mo ago
    Agree. Many times what the server returns is dictated by what kind of client software a user is using. Cookies are obviously used by browser based clients, with full browser capabilities. MCP doesn't have those capabilities. How will the server know what to return? I have separated handling for token based calls vs cookie based in my non-mcp projects.. because it suffers from the same issue. Most of the endpoints, assuming the client talks to server using api's, work fine with cookies, some, do not.
krooj 3mo ago
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.
- dend 3mo ago
  Was great collaborating with you and your team on this!
  - krooj 3mo ago
    Same!
ai_fry_ur_brain 3mo ago
Why does my text autocomplete cli need an ability to sign into things?
- ai_fry_ur_brain 3mo ago
  Why do people downvote this.. If your mediocre ai agent needs to use something that requires authentication you should be abstracting away the authentication, provide it a cli with cmds that have authentication baked in.
sandeepkd 3mo ago
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.
- dend 3mo ago
  There's theoretically nothing really stopping this integration from working in the consumer space - you just need to establish a trust relationship (e.g., if I am logged in with GitHub, also log me in to Sentry automatically). There is more work ahead here, but as you said - the most obvious _current_ use-case is enterprises, where admins do not want individual employees clicking around picking random credentials they have.
  - sandeepkd 3mo ago
    At the end of the day its wiring the flows to serve a purpose and can be wired in multiple ways. Some combination of client, IDP and resource server can come together to form a band and may provide this for consumer identity. Reasons why this is a bad idea for consumer identity - 1. In Enterprise, the IDP is the single owner for the identity, so it essentially can do represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity) 2. In enterprise the IDP is the single authentication factor used by the downstream resource server (application), in other words the application just trusts the assertion 3. For consumer identity, the resource server owns the identity/user explicitly. Github may be one of the authentication factors that the user can use, but it may not be the only one. 4. For consumer identity, Github cannot delete the user account in downstream application. Regardless, this protocol is going to create friction in adoption of new AI agents and MCP servers, to sell to enterprise they have to implement this and integrate with existing IDP's and resource servers. Using any new MCP server would require full evaluation lifecycle from security perspective. Its a good thing but its going to hurt the new players pretty bad in terms of adoption and discovery.
defytonofficial 3mo ago
[dead]
programmancer 3mo 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.
- hobofan 3mo ago
  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 https://erato.chat/docs
  - Aldipower 3mo ago
    [flagged]
- erebe__ 3mo ago
xdnaimino 3mo ago
[flagged]
arggjarvs 3mo ago
[flagged]
jkwang 3mo ago
[dead]
Omniloop 3mo ago
[dead]
theauthkid 3mo ago
[flagged]
ashu1461 3mo ago
Looks like something which will be only helpful for bigger companies who have centralised auth. Good step nonetheless
- mooreds 3mo ago
  Yeah, I read this and thought "makes total sense that Okta would be one of the prime movers behind this". The more I think about it, the more this is just like an app dashboard that an employee can use to access many different apps and that the enterprise can use to control and monitor access. So it makes total sense that they solved this (very real) problem. I like one of the author's characterizations[0]. > Now employees no longer have to connect MCP servers manually and wait for a series of OAuth and login prompts. Once you log in to Claude from Okta, all the preconfigured MCP servers are already connected! It's not every day you get to improve both usability and security! 0: https://aaronparecki.com/2026/06/18/12/claude https://aaronparecki.com/2026/06/18/12/claude
implexa_founder 3mo ago
[dead]
tuckerpo 3mo ago
> zero touch > look inside > there's a touch
mcpvet 3mo ago
[flagged]
zahan 3mo ago
[flagged]

278 points by niyikiza 3mo ago

Jimmy0252 3mo ago

[flagged]

idoma 3mo ago
thank you mr. LLM
- takethebus 3mo ago
  my account is too new I can't flag them :/

paulddraper 3mo ago

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

RVuRnvbM2e 3mo ago

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

maxwellg 3mo ago
In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department. Enterprise-Managed OAuth, or Cross App Access (XAA), brings this IT-Admin centrally controlled sharing model into the OAuth framework so it works with the existing ecosystem. There's also a great UX benefit from moving data sharing consent management from employees to IT Admins - it means that employees don't need to sit through a bunch of OAuth flows to link their accounts together. Their IT Admin has already set up all the sharing controls. Everything plugs in together and should Just Work from day one. Think joining a new company on the first day and your Slack is already linked to your Zoom, your Drive, your Calendar, etc...
- amluto 3mo ago
  This is bonkers. Sure, if I’m a business, I will make a business decision to share, or not share, some resource with ChatGPT. But, if I do decide to share something with ChatGPT, I absolutely do NOT want it shared with every single ChatGPT thread, more or less how I don’t want it shared with every single tab an employee has open in a browser.
  - qt31415926 3mo ago
    Isn't that what's solved by this method? Your SSO provider (e.g. Okta) is now what gates each employee's resource access for different MCP resources.
    - amluto 3mo ago
      I don't think so. The article is all about reducing friction. Suppose I start a conversation and enter some highly third-party-prompt-injectable request, perhaps "Fork github.com/some_third_party/coolproject and submit a PR to do such-and-such." That repo injects a prompt that attempts to do a tool call to steal all my money. If I indeed have a bank MCP configured, I absolutely want to be prompted! Now I realize it's silly for the prompt to look like "Would you like to grant [OpenAI/Anthropic/whatever] access to such-and-such account with such-and-such OAuth resources?", but having some kind of explicit opt-in, per conversation, to MCP access seems really quite important. But the article all about reducing friction and avoiding prompts. So maybe LLM providers will do a good job, but I'm not holding my breath.
      - iugtmkbdfil834 3mo ago
        << The article is all about reducing friction. I read the initial paragraph from the page and I had similar reaction with an additional touch of: 'There is a purpose for that friction.'
      - deleted 3mo ago
        [deleted]
      - 3mo ago
megous 3mo ago
Advantage is user has no control/is not needed to consent about what apps they're authorizing to share their information between each other, bacause the decision to delegate access is at the IdP policy level. User many never know which apps/services were authorized to share their information. Wait, is that an advantage? ;-)
- sandeepkd 3mo ago
  For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.
  - yammosk 3mo ago
    As someone who has been creating agentic workarounds at my large employer and in a lot of conversations with security as a result, this does not seem to be a huge advantage from the company side. They are very much invested in users being aware of what they permit. The company does want the final say either with shutting down a compromised user or blocking one service from agents and allowing the other, but they 100% do still want employees to be actively engaged and applying their own consent. Removing that from the employee also removes the employee from responsibility for any breach of information IMO, and companies definitely don't want that lol. What they do want is users to stop complaining about the annoying reauth every 8-12 hours for a dozen services which this does. The kinds of wishlists I hear are more about users managing fine-grain service permissions for various agentic roles and managing which agents have access to which role, which leans the other direction. They want to allow users are to treat agents like cloud services and have a greater responsibility for applying least privilege, justify leak risks, etc. The onus to protect this data will always be an employee responsibility in the end.
    - sandeepkd 3mo ago
      I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle. What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.

brap 3mo ago

I thought we’re over this collective delusion called MCP

isubkhankulov 3mo ago
MCP is just an API designed to be token frugal
- NamlchakKhandro 3mo ago
  Frugal is definitely not a word i would use in the same sentence as mcp
  - connor4312 3mo ago
    It's as frugal as your harness makes it. It's just a bunch of tools and a description of how to use them. Most mature harnesses do some kind of tool search and/or progressive disclosure. Many harnesses have some smarts to page out overwhelming results to a file so a model can grep/jq them easily. Some harnesses expose tool schema to models so their results can be directly transformed or even chained in [code mode](https://blog.cloudflare.com/code-mode/ https://blog.cloudflare.com/code-mode/).
mikestorrent 3mo ago
I thought we were all smarter than directly giving agents access to all of our long lived tokens
stackedinserter 3mo ago
Why is it delusion? What are better ways to make LLM talk to other services?

lorecore 3mo ago

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.

dend 3mo ago
We're always looking at making it a smoother experience - it's a top pain point for developers and IT admins alike. If you have feedback - feel free to send it my way!

maxwellg 3mo ago

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-assertion-authz-grant/ 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.

asdfsa32 3mo ago
Software and quality of life is worst because of these companies. So congrats to them indeed.

ericchiang 3mo ago

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?

dend 3mo ago
The standard itself is not MCP-specific. As long as the client and the server adopt ID-JAG, they're golden. RFC draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/ https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...

sean_lynch 3mo ago

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.

brookst 3mo ago
I agree that having auth outside of context window is good. But the real value of MCP is adding a semantic layer on top of APIs. Skills are client side and don’t know the server’s capabilities. MCP lets the server explain its API in natural language so clients who have no prior knowledge of the server, it’s API, or its domain can use it intelligently. I used to think MCP was dumb. I’ve written to large MCP servers, one for CAD and one for music, and I am a complete convert.
Ferret7446 3mo ago
> The real valuable capability MCP offers over skills/CLI is The real lesson is that MCP vs skills is not a binary. They are simply different tools. Each may or may not be better given different requirements. Which is better, a knife or a saw?
- fnordpiglet 3mo ago
  There’s even a skills over MCP WG; and I typically deliver skills via tools in my MCPs intentionally. I find Claude and codex recall of skills via MCP tools to actually be higher than skills themselves, which I feel have an (unmeasured) less than 30% recall rate. I have to typically force skills to be loaded explicitly through / or $ depending on the flavor and skill graphs are very unreliable.
imazhar101 3mo ago
[flagged]

dend 3mo ago

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.

mikestorrent 3mo ago
Fantastic news. Is there any communication between you folks and the Microsoft Entra (Azure AD) team? Would love to know if we can expect this soon or if will take a while.
- dend 3mo ago
  We are in touch with the Microsoft Entra ID folks to see how we can better integrate EMA in their stack!
  - 9dev 3mo ago
    While you're at it, bug them a bit to finally add support for MCP servers in Copilot. I'm on an Odyssey to find a way for our customers to use our MCP within their Copilot environment…
  - mikestorrent 3mo ago
    Fantastic, appreciated.
brianjking 3mo ago
Great work, thank you for doing this. Just so I understand, this isn't yet available yet, right? Still in SEP stage?
- dend 3mo ago
  It is available! The feature is available in Claude, with Okta being the first IdP to support it (hopefully more coming soon) and with a bunch of MCP partners launching with us today. The underlying extension has been in the MCP protocol for some time and is now officially stable.

hparadiz 3mo ago

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

dend 3mo ago
What's interesting about this standard is that it's not really MCP-specific. It can work just as nicely for any other workload - it just requires the authorization server/IdP to support it and the receiver to know how to handle the trust relationship.

flashgordon 3mo ago

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 3mo ago

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-authorization/overview https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

dend 3mo ago
Love more adoption of EMA and, of course, better infra for MCP developers. Thanks for such a quick turnaround on this feature work!

rvz 3mo ago

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.

dend 3mo ago
FWIW, we never vibe-coded the spec to begin with, but yes - auth is a continuous learning process, and we're lucky to collaborate with some really talented folks both inside and outside the company (e.g., this launch we worked closely with Okta to see how we can best wire things up) to make this a smoother experience. Keep the feedback coming!

joeyguerra 3mo ago

I have my chatbot command my chatbot.

zackify 3mo ago

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.

dend 3mo ago
Hey - one of the lead maintainers of the MCP project here. There are a lot of scenarios where this simply won't scale (both from a usability and security standpoint). Cookies were made for the browser. MCP servers and clients often operate in environments where that is not a guarantee.
- deleted 3mo ago
  [deleted]
- SkyPuncher 3mo ago
  I've been working on an MCP for creating semi-deterministic flows in Claude code (essentially skills, but broken down into pieces). In order to track execution and state, I have the LLM pass the MCP a unique "execution id" with every call. This lets me programmatically step it through skills and know exactly where execution progress is. I've been considering a similar approach for the web. Essentially, do a short-lived, one-time use token exchange for every single call back and forth. * LLM: "I'd like to interact with your site" * Site: "Great, here's first token. I will exchange it for a new one on the next call. Do not share with with another site. You can authenticate in your browser with this link: [example.com]" * Then you can go back and forth. It'd be rather annoying to auth in the browser every time, but it would enable a low-touch flow. Long term, it'd be ideal to have some sort of out-of-band credential store/tool available, but this would start proving the concept out. Don't use it for highly sensitive stuff, but it would enable a lot of agentic flows that are currently blocked by high-lift MCP setup.
- freakynit 3mo ago
  Agree. Many times what the server returns is dictated by what kind of client software a user is using. Cookies are obviously used by browser based clients, with full browser capabilities. MCP doesn't have those capabilities. How will the server know what to return? I have separated handling for token based calls vs cookie based in my non-mcp projects.. because it suffers from the same issue. Most of the endpoints, assuming the client talks to server using api's, work fine with cookies, some, do not.

krooj 3mo ago

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.

dend 3mo ago
Was great collaborating with you and your team on this!
- krooj 3mo ago
  Same!

ai_fry_ur_brain 3mo ago

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

ai_fry_ur_brain 3mo ago
Why do people downvote this.. If your mediocre ai agent needs to use something that requires authentication you should be abstracting away the authentication, provide it a cli with cmds that have authentication baked in.

sandeepkd 3mo ago

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.

dend 3mo ago
There's theoretically nothing really stopping this integration from working in the consumer space - you just need to establish a trust relationship (e.g., if I am logged in with GitHub, also log me in to Sentry automatically). There is more work ahead here, but as you said - the most obvious _current_ use-case is enterprises, where admins do not want individual employees clicking around picking random credentials they have.
- sandeepkd 3mo ago
  At the end of the day its wiring the flows to serve a purpose and can be wired in multiple ways. Some combination of client, IDP and resource server can come together to form a band and may provide this for consumer identity. Reasons why this is a bad idea for consumer identity - 1. In Enterprise, the IDP is the single owner for the identity, so it essentially can do represent the user uniquely and sort of pretty much do anything it wishes for (includes deleting the identity) 2. In enterprise the IDP is the single authentication factor used by the downstream resource server (application), in other words the application just trusts the assertion 3. For consumer identity, the resource server owns the identity/user explicitly. Github may be one of the authentication factors that the user can use, but it may not be the only one. 4. For consumer identity, Github cannot delete the user account in downstream application. Regardless, this protocol is going to create friction in adoption of new AI agents and MCP servers, to sell to enterprise they have to implement this and integrate with existing IDP's and resource servers. Using any new MCP server would require full evaluation lifecycle from security perspective. Its a good thing but its going to hurt the new players pretty bad in terms of adoption and discovery.

defytonofficial 3mo ago

[dead]

programmancer 3mo 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.

hobofan 3mo ago
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 https://erato.chat/docs
- Aldipower 3mo ago
  [flagged]
erebe__ 3mo ago

xdnaimino 3mo ago

[flagged]

arggjarvs 3mo ago

[flagged]

jkwang 3mo ago

[dead]

Omniloop 3mo ago

[dead]

theauthkid 3mo ago

[flagged]

ashu1461 3mo ago

Looks like something which will be only helpful for bigger companies who have centralised auth. Good step nonetheless

mooreds 3mo ago
Yeah, I read this and thought "makes total sense that Okta would be one of the prime movers behind this". The more I think about it, the more this is just like an app dashboard that an employee can use to access many different apps and that the enterprise can use to control and monitor access. So it makes total sense that they solved this (very real) problem. I like one of the author's characterizations[0]. > Now employees no longer have to connect MCP servers manually and wait for a series of OAuth and login prompts. Once you log in to Claude from Okta, all the preconfigured MCP servers are already connected! It's not every day you get to improve both usability and security! 0: https://aaronparecki.com/2026/06/18/12/claude https://aaronparecki.com/2026/06/18/12/claude

implexa_founder 3mo ago

[dead]

tuckerpo 3mo ago

> zero touch > look inside > there's a touch

mcpvet 3mo ago

[flagged]

zahan 3mo ago

[flagged]