Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero-Touch OAuth for MCP

blog.modelcontextprotocol.io

Post reply on HN
Print view View original

61–70 of 124 posts

Re: Zero-Touch OAuth for MCP

#61

Post by niyikiza »

amluto wrote: post #54
niyikiza wrote: post #50

Earlier quoted context omitted.

There's some active discussions on task level authz and multi-hop delegation in the OAuth WG right now. WorkOS wrote a good overview of the open drafts [1]. (Disclosure: one of them is mine.) [1] https://workos.com/blog/oauth-multi-hop-delegation-ai-agents

I skimmed that. It seems to me: (a) A major problem where one agent can give dangerous instructions to another. (b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)? (c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec co…

I agree with the coarse permissions point, and I wouldn't bank on those services adding finer-grained scopes.

The idea in my draft is to do the attenuation and verification before the call reaches the service, enforced at the boundary, like the proxy setup you're describing. And the token wouldn't be a bearer token per se; there's proof of possession, and the constraints narrow at each hop and travel with the token, so the boundary can verify the chain itself rather than rely on a central authority. The design is inspired by macaroons and other capability-based access control work.

Full draft's here if you want to pick it apart: https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenu...

Re: Zero-Touch OAuth for MCP

#63

Post by yammosk »

sandeepkd wrote: post #57
megous wrote: post #30

Earlier quoted context omitted.

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? ;-)

For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.

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.

Re: Zero-Touch OAuth for MCP

#64

Post by killix »

sean_lynch wrote: post #14

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…

[flagged]

Re: Zero-Touch OAuth for MCP

#65

Post by maxrev17 »

sean_lynch wrote: post #14

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…

Mcp allows a fantastic audit trail also. As well as allowing segregation of responsibilities - ie authenticating 6 linear accounts across 6 clients and then deciding which one to use with deterministic audited methods

Re: Zero-Touch OAuth for MCP

#66

Post by ai_fry_ur_brain »

ai_fry_ur_brain wrote: post #51

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

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.

Re: Zero-Touch OAuth for MCP

#67

Post by sandeepkd »

yammosk wrote: post #63
sandeepkd wrote: post #57

Earlier quoted context omitted.

For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.

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%…

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.

Re: Zero-Touch OAuth for MCP

#68

Post by programmancer »

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.

Re: Zero-Touch OAuth for MCP

#69

Post by hobofan »

programmancer wrote: post #68

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 capabili…

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

Re: Zero-Touch OAuth for MCP

#70

Post by hobofan »

amluto wrote: post #28
qt31415926 wrote: post #18

Earlier quoted context omitted.

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.

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…

Just to be clear, enforcing proper access control and data seperation is the job of a client (/harness), not the job of an LLM Provider (though of course the most popular clients are the first party clients for the LLM providers).

Ensuring that an LLM doesn't have free reign over calling any MCP tool at any point in time is one of the main jobs of a client (apart from the general data persistence, etc.), and one that's very dependent on the setup (e.g. many MCP servers expose public data where tool calling is mostly not that sensitive) and the acceptable risk profile.

This MCP extension also doesn't significantly change anything about tool calling control from the perspective of the client. MCP servers were previously also authenticated once per user, and not once per conversation or once per tool call.

Post reply on HN