HI version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
86% Positive
Analyzed from 1267 words in the discussion.
Trending Topics
#mcp#oauth#auth#folks#server#data#user#don#share#access
Discussion (34 Comments)Read Original on HackerNews
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.
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-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.
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!
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.
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.
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.
I'm just curious internally how you are seeing MCP adoption? It seems more and more connectors are created but are you seeing real adoption from users?
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...
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?
RFC draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...
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...
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.
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.