Streamlining MCP Authentication with Cross-App Access (XAA)

workos · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise MCP authentication and AI-agent access governance

WorkOS describes MCP authentication friction where every MCP client-to-server connection repeats OAuth consent, while enterprise IT teams lack centralized visibility, control, and revocation for AI-agent access to sensitive systems.

Constraints:

Developers can use half a dozen to a dozen MCP servers, multiplying consent screens across teams.
Standard OAuth assumes apps do not know or trust each other, which conflicts with enterprise SSO expectations.
IT teams cannot easily see which MCP clients and servers users connect or revoke lingering tokens after offboarding or compromise.
The solution must work across MCP clients, MCP servers, resource authorization servers, identity providers, and regular OAuth access tokens.

Architecture

WorkOS proposes Cross-App Access for MCP using the ID JAG identity JWT authorization grant. An MCP client such as Claude or Cursor logs into an enterprise IdP such as Okta, requests an ID JAG token for a target MCP server such as Figma, sends it to the server's authorization server, receives a standard short-lived OAuth access token, and then talks to the MCP server. IT configures managed connections that allow one app to request access to another.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  it_admin["IT admin"] --> managed_connections_policy["Managed connections policy"]
  managed_connections_policy --> identity_provider["Identity provider"]
  mcp_client["MCP client"] --> identity_provider
  mcp_client --> resource_authorization_server["Resource authorization server"]
  identity_provider --> resource_authorization_server
  resource_authorization_server --> mcp_server["MCP server"]
  mcp_client --> mcp_server

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`MCP client`	Claude Code, Cursor, or another AI client requesting access to MCP servers.	`Identity provider`, `Resource authorization server`, `MCP server`
`Identity provider`	Enterprise IdP such as Okta that authenticates users, issues ID/refresh tokens, and issues ID JAG tokens.	`MCP client`, `Managed connections policy`, `Resource authorization server`
`Managed connections policy`	IT-managed policy defining which client app may request access to which resource app.	`Identity provider`
`Resource authorization server`	Authorization component for the target MCP server that validates ID JAG and issues OAuth access tokens.	`MCP client`, `Identity provider`, `MCP server`
`MCP server`	Resource server such as Figma's MCP server/API that receives regular OAuth access tokens.	`MCP client`, `Resource authorization server`
`IT admin`	Configures allowed cross-app connections and revokes access through the IdP.	`Managed connections policy`, `Identity provider`

Data flow

A user logs into the MCP client through Okta and receives ID/refresh tokens. The client asks Okta for an ID JAG token for the target MCP server. Okta checks whether the user belongs to both apps and whether the client may request that access. The client sends the ID JAG token to the MCP server's authorization server, which validates it with Okta, issues a regular OAuth access token, and the client uses that token for normal MCP calls.

4 supporting quotes

“the user goes through SSO to the IDP. And that issues back an ID token and refresh token.”transcript, stated

“So, the client goes back to the IDP and says, "Hey, I have this refresh token for Garrett. Would you please give me this ID Jag token that will work with Figma?"”transcript, stated

“Figma, because it has this relationship with Octa, goes through, verifies the ID Jag. Once that's verified and correct, it is then able to issue this access token”transcript, stated

“step four here is the regular MCP off flow. So, it just starts talking to the MCP server. It's using a regular OAuth access token.”transcript, stated

Why this architecture

XAA uses the enterprise IdP as the trust bridge because both the MCP client and target application already trust SSO. This removes repeated consent screens, centralizes IT policy, and improves security because short-lived access tokens stop refreshing once the SSO session or app membership is revoked.

3 supporting quotes

“XAA is basically a way in which the identity provider can act as a stand-in, a trust provider between applications.”transcript, stated

“They can both depend on that trust reliance on Okta, and they can get credentials issued without manual or human intervention.”transcript, stated

“once that access token expires, I won't be able to get back in. I won't be able to reconnect to that MCP server.”transcript, stated

Models used: MCP clients · Claude Code · Cursor

Scale

A user might log into half a dozen or a dozen MCP servers.
“as a user you might log into a half dozen or a dozen MCP servers.”transcript, stated
Across a team this becomes dozens of people repeatedly managing consent screens.
“you basically have dozens and dozens of people spending all this time managing all these consent screens”transcript, stated
Most applications issue access tokens around five minutes.
“most applications issue access tokens around 5 minutes.”transcript, stated
Lingering MCP OAuth tokens can last days, weeks, or months under the old flow.
“that means that, uh, you have this like lasting access problem that IT doesn't have any visibility over.”transcript, stated
“that give you standing access to these services. That means you might have access for, uh, days or weeks or even months.”transcript, stated

Alternatives considered (roads not taken)

Standard MCP OAuth consent per server

Rejected because: It creates repeated consent screens and persistent access tokens that IT cannot centrally see or revoke.

“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.”transcript, stated

“you still have these access tokens, these refresh tokens even in most cases that give you standing access to these services.”transcript, stated

Manual IT setup plus user reauthentication

Rejected because: IT might set up MCP servers in Claude or Cursor, but users still need to authenticate and manage connections manually.

“IT might be able to like automatically set up the MCP servers you're using in something like Cursor or Claude, um, but you still need to go through all this authentication”transcript, stated

Long-lived standing credentials on local machines

Rejected because: The presenter describes compromise/offboarding scenarios where API keys and refresh tokens create revocation problems.

“What services might I have some sort of other credential not driven from the IDP that, you know, is at risk of being leaked?”transcript, stated

Patterns

`safety-policy-enforcement` (identity governance)

XAA lets IT configure which client app may request access to which resource app and revoke access through the IdP.

“Inside of a system like Octa, there's this new kind of managed connections portal.”transcript, stated

“Cursor is allowed to request this access out of Figma.”transcript, stated

`tool-use-orchestration` (agent integration)

The flow enables MCP clients to authenticate to MCP servers automatically and then use normal MCP calls with a regular OAuth access token.

“once that's done, number four is your standard just talk to an MCP server. So, nothing new there.”transcript, stated

`privacy-preserving-processing` (credential security)

Short-lived access tokens tied to SSO reduce lingering local access after compromise or offboarding.

“you actually have a better security posture where if something happens and, you know, my access is removed for some reason”transcript, stated

“once that access token expires, I won't be able to get back in.”transcript, stated

`human-in-the-loop-gate` (administration)

IT admins explicitly configure managed connections in the IdP before one app can request access to another.

“which app do I want to grant the ability to request access to this other app?”transcript, stated

Tradeoffs

Use the identity provider as a trust bridge.

Chose XAA with ID JAG tokens over Independent OAuth consent between each MCP client and server.

Rationale: The IdP already authenticates both applications and can enforce enterprise policy without repeated user consent.

“both Cursor and Figma already have this trust relationship with Okta”transcript, stated

“What cross-app access does, it helps bridge the gap between Cursor and Figma by providing a way for Cursor to talk to Figma.”transcript, stated

Keep standard OAuth access tokens at the MCP server boundary.

Chose ID JAG exchange followed by regular OAuth access token over Inventing a new credential type for MCP resource access.

Rationale: After exchange, the MCP server flow remains standard, minimizing integration changes.

“It's using a regular OAuth access token. It's not a new type of credential.”transcript, stated

“number four is your standard just talk to an MCP server. So, nothing new there.”transcript, stated

Prefer short-lived access tokens with automatic refresh.

Chose Five-minute-style access tokens refreshed through SSO-backed ID JAG exchange over Long-lived local refresh tokens and API keys.

Rationale: Short-lived tokens reduce standing access after revocation while keeping user experience automatic.

“that token will expire after 5 minutes, but you don't need the human to do anything.”transcript, stated

“You can basically rerun this ID Jag flow plus the exchange and get a new access token as needed.”transcript, stated

Gotchas (what bit them)

MCP's OAuth flow creates consent-screen fatigue.

Root cause: OAuth assumes two applications do not trust each other, so each MCP client/server connection asks for consent.

Resolution: Use XAA so the identity provider bridges trust between applications without manual consent per server.

“It uses OAuth as the underlying, uh, authentication layer.”transcript, stated

“They can both depend on that trust reliance on Okta, and they can get credentials issued without manual or human intervention.”transcript, stated

IT lacks visibility into arbitrary MCP client/server connections.

Root cause: Users can connect AI agents to sensitive systems without going through the IdP for every connection.

Resolution: Route cross-app access through managed IdP policy so IT knows which apps can request access.

“IT can't really tell like what MCP service you may or may not be using.”transcript, stated

“They basically can't determine, uh, you know, which AI agents you can actually use”transcript, stated

Offboarding or device compromise can leave MCP tokens alive.

Root cause: Standard MCP OAuth leaves access and refresh tokens outside central SSO revocation paths.

Resolution: Use short-lived access tokens refreshed only while the SSO session and ID JAG flow remain valid.

“you still have these access tokens, these refresh tokens even in most cases that give you standing access to these services.”transcript, stated

“as long as your SSO session is active, you can keep getting these ID Jag tokens, exchanging them for access tokens.”transcript, stated

Evaluation

The talk demonstrates an XAA-compatible Claude Code flow and evaluates the design qualitatively against user-friction, IT visibility, and security-posture problems.

Metrics: A user may connect to half a dozen or a dozen MCP servers. · Access tokens are commonly around five minutes. · The demo removes per-server consent screens after the initial Okta login.

“I didn't have to click anything. I didn't have to see a consent screen.”transcript, stated

“most applications issue access tokens around 5 minutes.”transcript, stated

Outcomes

The XAA-compatible Claude Code demo automatically connected the Figma MCP server after Okta login.
The flow centralizes policy in managed IdP connections.
Short-lived tokens improve revocation behavior compared with standing access tokens and refresh tokens.

The source discusses enterprise teams where many developers each connect to multiple MCP servers, not a deployed production metric from a single customer.

“Figma is automatically connected”transcript, stated