One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS

Key Concepts

• MCP (Model Context Protocol): An open standard that enables AI assistants to connect to external data sources and tools.
• XAA (Cross-App Access): A framework that allows an Identity Provider (IDP) to act as a trust broker between applications, eliminating the need for repetitive manual consent screens.
• ID-JAG (Identity JWT Authorization Grant): A technical specification (token type) used by an IDP to issue credentials that allow one application to access another on behalf of a user.
• SSO (Single Sign-On): An authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems.
• DCR (Dynamic Client Registration): A protocol for clients to register themselves with an authorization server; being superseded by newer metadata standards.

1. The Problem: "Consent Fatigue" and Security Risks

The current implementation of MCP relies heavily on standard OAuth flows, which were designed for systems that do not inherently trust each other. This creates two primary issues:

• User Experience: Users must manually approve consent screens for every single MCP server they connect to (e.g., Figma, Notion). This is repetitive, annoying, and often redundant.
• IT/Security Governance: IT teams lack visibility into which AI agents employees are using. Because connections are made locally, IT cannot easily revoke access or audit which sensitive systems (like Figma or Notion) are being accessed by AI tools. Furthermore, if a machine is compromised, existing OAuth refresh tokens can provide "standing access" to services even after an employee leaves or their primary SSO session is terminated.

2. The Solution: Cross-App Access (XAA)

XAA bridges the gap between an MCP client (e.g., Cursor, Claude) and an MCP server (e.g., Figma) by leveraging the existing trust relationship both have with a central Identity Provider (e.g., Okta).

The Step-by-Step Process:

1. Initial SSO Login: The user logs into their company’s IDP (e.g., Okta) once.
2. ID-JAG Request: The MCP client requests an ID-JAG token from the IDP, presenting the user's existing refresh token.
3. Validation & Exchange: The IDP verifies that the user has access to both the client and the target server. It issues an ID-JAG token, which the client then sends to the MCP server’s authorization server.
4. Access Token Issuance: The MCP server validates the ID-JAG token and issues a standard OAuth access token to the client.
5. Execution: The client uses the standard access token to interact with the MCP server.

Key Benefit: Steps 2 and 3 occur entirely in the background without human intervention. The user only logs into the IDP once, and the system handles the rest.

3. Implementation Requirements

• For IT Admins: Configure the IDP (e.g., Okta) to recognize the "audience" (the specific MCP server) and grant the MCP client permission to request access to that audience.
• For MCP Clients: Must support XAA-compatible SSO and be able to handle the ID-JAG token exchange flow.
• For MCP Servers: Must support the JWT bearer token type, verify the ID-JAG token against the IDP, and issue the final access token.

4. Notable Quotes and Perspectives

• On the current state of MCP: "If you've used MCP at all extensively, you know that it means consent screens on top of consent screens on top of consent screens." — Garrett Galo
• On Security: "If something happens... you still have these access tokens... that give you standing access to these services... that means you might have access for days or weeks or even months." — Garrett Galo
• On the future of the ecosystem: The speaker noted that while Okta currently supports XAA, they are actively working with Microsoft (Entra) to adopt the standard, as broad industry adoption is necessary to solve the current fragmentation.

5. Synthesis and Conclusion

The current MCP authentication model is a significant bottleneck for enterprise adoption due to "consent fatigue" and security blind spots. Cross-App Access (XAA) provides a robust, scalable framework that shifts the burden of trust from the individual user to the enterprise Identity Provider. By utilizing ID-JAG tokens, organizations can maintain strict security policies, ensure automatic revocation of access, and provide a seamless, "magic" experience for developers using AI agents. While the ecosystem is still maturing—specifically regarding support for Microsoft Entra and newer metadata standards—XAA represents the necessary evolution for AI tools to become enterprise-ready.