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

21–30 of 124 posts

Re: Zero-Touch OAuth for MCP

#21

Post by 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!

Re: Zero-Touch OAuth for MCP

#22

Post by brookst »

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…

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.

Re: Zero-Touch OAuth for MCP

#23

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

Re: Zero-Touch OAuth for MCP

#24

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

Re: Zero-Touch OAuth for MCP

#25

Post by dend »

russell_h wrote: post #23

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…

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

Re: Zero-Touch OAuth for MCP

#26

Post by dend »

rvz wrote: post #24

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…

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!

Re: Zero-Touch OAuth for MCP

#27

Post by dend »

ericchiang wrote: post #13

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?

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

Re: Zero-Touch OAuth for MCP

#28

Post by amluto »

qt31415926 wrote: post #18
amluto wrote: post #10

Earlier quoted context omitted.

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.

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

Re: Zero-Touch OAuth for MCP

#29

Post by iugtmkbdfil834 »

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…

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

Re: Zero-Touch OAuth for MCP

#30

Post by megous »

RVuRnvbM2e wrote: post #5

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

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? ;-)
Post reply on HN