Comment by RVuRnvbM2e
1 day ago
I don't quite understand the advantage of this over regular oauth. I think I need an example comparison of the authz flows.
1 day ago
I don't quite understand the advantage of this over regular oauth. I think I need an example comparison of the authz flows.
In regular OAuth, end users consent to share their data with applications individually. This makes sense for consumer usecases, where the end users own their data. But it doesn't make sense for many business usecases, where the business is the entity that should control data sharing and access, not the end user. As an employee at Acme, I shouldn't decide to link my Acme Google Drive data to Claude or ChatGPT, that should be the decision of my IT Department.
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...
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.
8 replies →
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 organizations it's definitely an advandtage, as it also allows for preventing data flowing to personal accounts. Right now, any employee could knowingly or unknowingly exfiltrate data, by just connecting to e.g. the personal instead of the organization's JIRA account, and there is essentially no standard way to guard against that as an organization.
That's also blind spot in normal OAuth and I was surprised to find that this was never addressed in all the years that non-MCP OAuth found adoption.
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.
1 reply →