4 ms·

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

maxwellg 4mo ago
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...
- amluto 4mo ago
  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.
  - qt31415926 4mo ago
    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.
    - amluto 4mo ago
      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.
      - iugtmkbdfil834 4mo ago
        << The article is all about reducing friction. 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.'
      - deleted 4mo ago
        [deleted]
      - niyikiza 4mo ago
        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 https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
        amluto 4mo ago
        I skimmed that. It seems to me: (a) A major problem where one agent can give dangerous instructions to another. (b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)? (c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation. ISTM: - (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner. - (b) could be addressed by a capability or proxy system. - Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting. - Why would one ever want to give a bearer token to an “agent”? - Wouldn’t a proxy serve this purpose more flexibly and more universally?
megous 4mo ago
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? ;-)
- sandeepkd 4mo ago
  For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.
  - yammosk 4mo ago
    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.
    - sandeepkd 4mo ago
      I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle. What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.

maxwellg 4mo ago

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

amluto 4mo ago
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.
- qt31415926 4mo ago
  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.
  - amluto 4mo ago
    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.
    - iugtmkbdfil834 4mo ago
      << The article is all about reducing friction. 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.'
    - deleted 4mo ago
      [deleted]
    - niyikiza 4mo ago
      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 https://workos.com/blog/oauth-multi-hop-delegation-ai-agents
      - amluto 4mo ago
        I skimmed that. It seems to me: (a) A major problem where one agent can give dangerous instructions to another. (b) A desire for an “agent” to cleanly delegate permissions to another “agent”. I am extremely unclear as to what an “agent” is in this context. Is one’s OpenAI or Anthropic account an “agent”? How is (b) related to (a)? (c) An observation that existing OAuth + JWT can’t really do (b) and that a new spec could allow delegation. ISTM: - (a)’s root cause is a complete lack of control on the portions of a repository that are interpreted by various tools in a trusted/privileged manner. - (b) could be addressed by a capability or proxy system. - Most services that offer OAuth or other types of API keys have absurdly coarse-grained permissions. GitHub’s OAuth cannot obviously even restrict to a particular organization, let alone a repository, and good luck blocking commits to .github. Cloudflare can’t restrict DNS operations to a particular host. A shocking number of major services have no concept of non-human accounts. The list goes on. Delegation is of dubious value in this setting. - Why would one ever want to give a bearer token to an “agent”? - Wouldn’t a proxy serve this purpose more flexibly and more universally?

megous 4mo ago

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

sandeepkd 4mo ago
For your employee account yes its an advantage, and thats the target. Your personal account will still require consents.
- yammosk 4mo ago
  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.
  - sandeepkd 4mo ago
    I am with you on the challenges with fine grain authorization needs, to me that part is real hard. In a theoretical world the IDP would know all the roles and permissions available for the different authorization servers (downstream services). However centralizing something like this would require some adoption of how permissions are managed by different resource servers, that is a different battle. What this gives your employer is the allow list of AI agents that you can use (the ones that can use your employer's IDP to access downstream MCP servers) and filters out all the MCP servers that do not implement this protocol. Essentially the threshold to use any AI agent or any MCP server would be a lot higher.