Live data from Hacker News

Zero-Touch OAuth for MCP

blog.modelcontextprotocol.io

41–50 of 124 posts

Re: Zero-Touch OAuth for MCP

#41
post #37
post #36

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.

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]

Re: Zero-Touch OAuth for MCP

#42
post #37
post #36

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.

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.

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.

Re: Zero-Touch OAuth for MCP

#43
post #36

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.

You're just asking for your credentials to get stolen. Long lived creds are a huge liability.

Re: Zero-Touch OAuth for MCP

#44
post #37
post #36

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.

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.

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.

Re: Zero-Touch OAuth for MCP

#45
post #15

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…

This is great for normal "apps". We have a really deep need for a lower touch way for our users to interact with us agentically without setting up MCP. It'd be really great to have some sort of temporary session or out-of-band token storage available.

Here's our use case: During the sales cycle, the buyer and seller need to exchange a bunch of information then analyze it (which is increasingly agentic). The problem with MCP is the initial setup friction is far greater than users login in themselves and grabbing the information they need. MCPs are great for regular, frequent interactions - but create a lot of problems for these quick one-off sessions.

We'd really love a way to do something like this:

* In Claude: "Grab documents from X, Y, Z"

* Claude hits that website, it returns (1) basic usage information (2) a login link that the user can open in their browser

* User auths in their browser (annoying, but mindless)

* That callback returns a unique, short-lived, one-time token that gets exchanged on all future requests to the site.

Now, we can quickly auth users AND maintain a session state as they do things.

Re: Zero-Touch OAuth for MCP

#46

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…

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

Re: Zero-Touch OAuth for MCP

#47

Earlier quoted context omitted.

MCP is just an API designed to be token frugal

Frugal is definitely not a word i would use in the same sentence as mcp

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

Re: Zero-Touch OAuth for MCP

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

Re: Zero-Touch OAuth for MCP

#49
post #28

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…

[deleted]

Re: Zero-Touch OAuth for MCP

#50
post #28

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…

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