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.
Zero-Touch OAuth for MCP
41–50 of 124 posts
Re: Zero-Touch OAuth for MCP
#42If 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 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
#43If 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.
Re: Zero-Touch OAuth for MCP
#44If 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.
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
#45Hey 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…
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
#46Before 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 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
#47Earlier 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
Re: Zero-Touch OAuth for MCP
#48Re: Zero-Touch OAuth for MCP
#49Earlier 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…
Re: Zero-Touch OAuth for MCP
#50Earlier 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…