▶ Watch (1:24)

MCP requires a separate consent screen for every tool. A user may log into half a dozen or a dozen MCP servers. Across a team, dozens of people click through these screens without reading them. The underlying OAuth model assumes apps don’t trust each other. For IT, the problem is worse. They cannot see which MCP services employees connect to. Access tokens persist for days or months. When a user leaves the company, IT has no way to revoke that standing access. The NPM Axios incident showed the gap: Galow’s machine was compromised, but MCP API keys were outside IT’s control.

XAA: Automatic Authentication Without Clicks

▶ Watch (8:41)

Galow showed a Claude code client with XAA enabled. He logged into Okta once. Then Figma’s MCP server connected automatically. No consent screen appeared. The whole point, he said, is that the user does nothing. Cross-App Access (XAA) uses the identity provider as a trust anchor. Both Cursor and Figma already trust Okta. XAA bridges the gap between them, issuing credentials without human intervention. The demo ran on a beta implementation built by WorkOS.

Behind the Scenes: ID Jag Token Flow

▶ Watch (9:37)

The flow involves four systems: client, identity provider (Okta), resource authorization server, and the MCP server. First, the user does SSO login, getting an ID token and refresh token. The client then requests an ID Jag token from the IDP — an identity JWT authorization grant. Okta checks that the user belongs to both the client app and the target app. It issues the ID Jag. The client sends that to Figma’s authorization server, which validates it and returns a regular OAuth access token. Steps two and three are invisible. Access tokens last about five minutes. If the SSO session is revoked, the client cannot get a fresh token after expiry.

Setup for IT, Clients, and Servers

▶ Watch (13:17)

On the IT side, the admin creates a managed connection in Okta, granting Cursor the ability to request access to Figma. The user must belong to both applications. The MCP client needs an XAA-compatible SSO connection. It requests the ID Jag token from the IDP and exchanges it with the server. The MCP server must support a new JWT bearer type, accept the ID Jag, verify it against the IDP, and issue an access token. WorkOS builds support for the token flows. Cursor and Anthropic use WorkOS for SSO, so they can adopt XAA.

Q&A

Does XAA solve authorization or just authentication? It handles authentication only; the user gets the same permissions they already have within the target app, though scoped access is under discussion. ▶ Watch (17:01)

How does the MCP client know which app to request in Okta? It uses an audience URL (e.g., mcp.figma.com) that is configured inside Okta as the target app’s identifier. ▶ Watch (18:13)

Does Microsoft Entra support XAA? Not yet. Okta supports it today for OIDC connections. WorkOS is working with Microsoft and other partners to expand support. ▶ Watch (19:19)

Notable Quotes

“consent screens on top of consent screens on top of consent screens” Garrett Galow · ▶ Watch (1:24)

“The whole point of this is you don’t have to do anything” Garrett Galow · ▶ Watch (9:29)

“most applications issue access tokens around 5 minutes” Garrett Galow · ▶ Watch (12:28)

Key Takeaways

  • OAuth consent screens for MCP create friction for users and blind spots for IT.
  • XAA uses ID Jag tokens from the identity provider to eliminate per-tool consent.
  • Short-lived access tokens and central revocation improve security posture.