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

Garrett Galow, head of product at WorkOS, presents Cross-App Access (XAA) as a solution to the fragmented OAuth consent-screen problem that plagues MCP server ecosystems. Galow opens by framing the pain point: developers using multiple MCP servers in tools like Cursor or Claude Code must independently authenticate to each one via OAuth consent screens, resulting in repeated logins, opaque token lifecycles, and a proliferation of standing credentials that IT teams cannot govern. WorkOS powers authentication for Anthropic, Cursor, and OpenAI, giving Galow direct insight into this problem at scale.

The core security argument goes beyond user inconvenience. Galow recounts a real incident involving the NPM Axios package compromise roughly a week before the talk: his machine was flagged, his Okta sessions were revoked centrally, but local MCP servers holding API keys and long-lived OAuth refresh tokens remained accessible — potentially for days, weeks, or even months — because those credentials were never brokered through the corporate Identity Provider (IDP). This highlights the principal gap: OAuth as originally designed assumed distrust between two unrelated systems, but enterprise environments already have SSO (Okta, Microsoft Entra) as a shared trust anchor, and MCP today ignores that.

XAA resolves this through a four-party protocol leveraging the Identity JWT Authorization Grant (ID Jag / IETF spec). The four parties are: (1) the MCP client (e.g., Claude Code), (2) the IDP (e.g., Okta), (3) the resource authorization server (e.g., Figma's auth service), and (4) the resource server (Figma's MCP API). The flow proceeds as follows: the user performs a single SSO login to the IDP, which issues an ID token and refresh token to the client. When the client needs access to a new MCP server, it silently requests an ID Jag token from the IDP for the target audience (e.g., mcp.figma.com). Okta validates that both the client app and the target app are registered under the organization and that the policy permits this delegation, then issues the signed JWT. The client presents this ID Jag token to Figma's authorization server, which independently verifies it against Okta's JWKS endpoint and issues a short-lived OAuth access token (typically ~5 minutes). Step four is standard MCP OAuth — the client uses that access token to call the MCP server. Steps two and three are entirely invisible to the user.

The short-lived access token model is a deliberate security improvement: once an Okta session is revoked (e.g., on device compromise or employee offboarding), the client can no longer obtain new ID Jag tokens, and existing access tokens expire within minutes rather than persisting for weeks. Galow demonstrates a live beta implementation in which a fresh Claude Code terminal, after a single Okta login, automatically shows Figma as connected with zero consent screens clicked.

On the IT admin side, setup involves creating a "managed connections" policy in Okta specifying which client apps may request access to which resource apps — a one-time configuration layered on top of existing SSO app registrations. WorkOS has already built XAA support for the client-side flows used by Cursor and Anthropic. For MCP server builders, the required changes are: advertise support for the new JWT bearer token type, accept and verify the incoming ID Jag JWT against the IDP's public keys, then issue a standard access token.

During Q&A, Galow clarifies that XAA addresses authentication only, not authorization scope management, though scoped delegation is on the roadmap. He confirms audience-based app resolution (the MCP client passes the target server's audience URL in its ID Jag request). Microsoft Entra does not yet support XAA; WorkOS is actively working with Microsoft to add it. Dynamic Client Registration (DCR) gaps in Entra also surfaced as a related fragmentation issue, with CIMD (a newer ~3-month-old metadata standard) cited as a long-term improvement over DCR.