One Login to Rule Them All: Cross-App Access for MCP — Garrett Galow, WorkOS
TL;DR
MCP’s OAuth UX is a consent-screen tax — Garrett Galow says tools like Cursor and Claude force users to re-authenticate every MCP server individually, creating “consent screens on top of consent screens” for Figma, Notion, and more.
The bigger problem is IT and security, not just annoyance — because MCP access often sits outside the company IDP, IT can’t reliably see which AI clients employees use or instantly kill standing access tokens when a machine is compromised or someone leaves.
Cross-app access (XAA) uses the IDP as the trust bridge — in Garrett’s example, Cursor or Claude already trust Okta, and Figma already trusts Okta, so Okta can issue an ID-JAG token that lets the client get a Figma token without a human clicking through OAuth again.
The live demo’s punchline was ‘log in once to Okta, and Figma is just connected’ — after a single Okta login inside an XAA-enabled Claude Code build, the Figma MCP server showed up as automatically authenticated with no extra consent screen.
Security actually improves because access becomes short-lived and centrally revocable — Garrett notes most app access tokens are around 5 minutes, so if Okta locks a session, the client can no longer refresh access through the invisible ID-JAG exchange.
This is real but early: Okta works, Microsoft Entra doesn’t yet — WorkOS says it has built the client-side support and is helping power this for Anthropic and Cursor, while broader ecosystem issues like Entra support, DCR gaps, and newer standards like CIMD are still catching up.
The Breakdown
The MCP pain everyone already knows
Garrett opens with the most relatable part of MCP today: endless OAuth prompts. In Cursor, every MCP server wants its own login and consent screen, and sometimes it forgets and asks again, which he calls “frankly pretty annoying.”
Why this stops being a UX gripe and becomes an IT problem
He quickly shifts from developer inconvenience to enterprise risk. In a company, dozens of people all doing these auth dances adds up, but worse, IT loses visibility into which AI clients are connected to sensitive systems like Figma or Notion and can’t easily enforce which agents are allowed.
The laptop compromise story that makes the risk real
Garrett shares that he got hit by the recent npm/Axios compromise and watched IT do the usual good stuff: detect the issue, cut off his network access, and invalidate Okta sessions. But then came the ugly part: hunting through his machine for MCP connections, local API keys, refresh tokens, and other credentials that lived outside the IDP and might still grant access for days, weeks, or months.
XAA: letting Okta vouch across apps
The proposed fix is cross-app access, or XAA. Garrett frames it simply: if both Claude/Cursor and Figma already trust the same identity provider like Okta, that IDP should be able to stand in as the trust broker so the client can obtain credentials for the MCP server without a fresh human consent flow every time.
The demo moment: Figma connects itself
He shows regular Claude Code on one side, where Figma still needs the normal auth click-through, and an XAA-compatible Claude Code build on the other. After a one-time Okta login, he launches Claude and the Figma MCP server is already connected — no popup, no approval screen, just “off to the races.”
What’s actually happening behind the curtain
Garrett breaks the magic into four systems: the client, the IDP, Figma’s authorization server, and the resource server itself. After SSO, the client uses its existing session to request an ID-JAG token from Okta, sends that to Figma’s auth server, gets back a normal OAuth access token, and then talks to the MCP server exactly as before.
Why this is better for security, not just convenience
The invisible steps are the point: once the user has an active SSO session, the client can keep re-running the exchange without bothering them. Because the resulting access tokens can be very short-lived — Garrett says most apps issue tokens around 5 minutes — cutting off the Okta session means access naturally dies on the next refresh instead of lingering as a forgotten long-lived token.
What teams need to implement — and the rough edges in the ecosystem
On the admin side, IT mainly configures which app can request access to which other app inside Okta’s managed connections portal. Clients need XAA-capable SSO and support for requesting and exchanging ID-JAG tokens; servers need to accept a new JWT bearer type, validate it against the IDP, and then issue access tokens. In Q&A, Garrett is clear that this solves authentication, not fine-grained authorization scopes yet, and that today Okta supports it while Microsoft Entra still does not.