One Login to Rule Them All: Cross-App Access for MCP

Why should connecting Cursor to Figma require another consent screen when you already use the same company login for both? That is the practical problem behind Garrett Galow’s walkthrough of enterprise MCP authentication. Galow introduces himself as the product lead at WorkOS, following nearly fifteen years building enterprise developer platforms at Microsoft Azure, Cloudflare, and WorkOS. He says WorkOS supplies authentication for Anthropic, Cursor, and OpenAI—including Cursor’s password and enterprise identity-provider logins.

In Cursor, you add MCP servers through a configuration file, then connect each server separately. Clicking Connect opens a browser window, presents a consent screen, and redirects you back to the client. Repeat for the next service. Sometimes an apparently forgotten connection sends you through the same process again. With half a dozen or a dozen servers per person, dozens of teammates end up managing a large collection of individual approvals.

The OAuth flow asks the user to authorize a relationship: Cursor may access their Figma account; Cursor may access their Notion account. Enterprise single sign-on, however, already establishes relationships between those applications and an identity provider such as Okta or Microsoft Entra. The MCP connection flow shown here does not carry that shared enterprise identity across applications. Signing into both applications through the same IdP therefore does not eliminate the separate delegation step.

Repeated consent is irritating for users, but the larger problem belongs to IT. If employees connect arbitrary MCP clients to arbitrary services without going through the company IdP, administrators lose a central place to observe and govern those connections. An approved Cursor installation and a potentially unapproved DeepSeek client can both become routes into sensitive Figma or Notion data when users grant access themselves.

Galow makes the risk concrete through his account of being affected by the axios npm supply-chain compromise roughly a week before the talk. He did not know which dependency had introduced the compromised package. IT detected the affected machine, cut off its network access, and invalidated his Okta sessions across applications. But local MCP connections and API keys required a separate investigation: which services had he connected, which credentials existed outside the IdP, and how could each one be revoked?

Revoking an SSO session does not necessarily revoke every credential obtained outside it. Galow warns that access tokens and, especially, refresh tokens can preserve standing access after an incident or an employee’s departure. Depending on service policies, he says that access can last days, weeks, or months. He points to SCIM provisioning as a way to close the account lifecycle gap, while noting that many companies do not deploy it. The same fragmentation appears during onboarding: IT may configure the MCP servers in Cursor or Claude, yet each employee still has to authenticate and manage the connections.

Cross-App Access, or XAA, makes the identity provider a trust intermediary between applications. Consider Cursor as the MCP client, Figma as the target service, and Okta as the company IdP. Cursor already trusts the company’s workos.okta.com instance to authenticate employees. Figma trusts that same instance. Both applications already know that the user belongs to them. XAA uses those existing relationships to obtain credentials for the client without another human consent interaction.

The demonstration starts in ordinary Claude Code with a configured Figma MCP server that still needs authentication. Connecting it would lead to the familiar consent flow. Galow then switches to a separate, explicitly beta, XAA-compatible version of Claude Code. Its connection to his Okta environment is already configured. He logs into Okta, starts Claude Code, and opens the MCP server list: Figma is connected without a separate consent click.

The visible difference is small because the purpose is to remove an interaction. Instead of individually authorizing each configured service, the user completes the enterprise login and the client obtains the permitted connections behind the scenes. Galow extends the same pattern from Figma to a list of MCP servers. The automatic connection is the demonstrated result; the credential exchanges explain how it happens.

The flow has four actors, with Figma’s authorization server separated from its resource server:

The resource server is the API the client wants to use. The authorization server is the system that decides whether to issue credentials for it; those are distinct responsibilities even when the same company operates both.

The first three steps establish access:

1. Sign into the IdP. In the demonstrated flow, Okta returns an ID token and a refresh token, which Claude Code retains.
2. Request an ID-JAG. An Identity Assertion JWT Authorization Grant is an IdP-issued assertion used to obtain access at another service. In Galow’s walkthrough, Claude Code uses its refresh token to request a grant for Figma. Okta checks both the user’s membership in the applications and the policy permitting Claude Code to request access to Figma.
3. Exchange the grant at Figma. Claude Code sends the ID-JAG to Figma’s authorization server. Figma validates it through its existing trust relationship with Okta, then issues an access token.

The Identity Assertion Authorization Grant draft describes the protocol family behind this exchange; the beta demonstration uses the refresh-token path Galow narrates.

At the shell level, the grant-to-access-token exchange is a form-encoded request that exchanges the ID-JAG for an access token. With FIGMA_TOKEN_ENDPOINT set to the target authorization server’s token endpoint and ID_JAG holding the issued assertion, its core request fields look like this:

curl --fail-with-body \
  --request POST "$FIGMA_TOKEN_ENDPOINT" \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \
  --data-urlencode "assertion=$ID_JAG"

The client also needs whatever client authentication its registration requires. The key boundary is that the ID-JAG goes to the authorization server, which validates it before issuing the resource credential.

The fourth step is ordinary MCP access: Claude Code sends requests using the OAuth access token Figma issued. XAA changes how the client obtains the credential, not the credential type the MCP resource server receives. Figma then returns the requested responses through the normal MCP interaction.

After the initial enterprise login, ID-JAG issuance and the exchange at Figma are invisible to the user. IT policy determines how often the user must authenticate interactively to the IdP; Galow gives daily and weekly login policies as examples. That interactive schedule is separate from the lifetime of a resource access token.

Galow uses a five-minute access token to illustrate renewal: after it expires, the client repeats ID-JAG issuance and exchange without asking the user to approve another connection. Five minutes is the example here, not an established lifetime for the demonstrated Figma token or a requirement of XAA.

As long as the SSO session remains active and policy permits access, the client can keep obtaining new grants and exchanging them for access tokens. If IT removes access or locks the Okta session, renewal fails. An already-issued access token can remain usable until it expires; central revocation prevents the next successful renewal. This brings continuing access back under the IdP’s control without making every short token lifetime another user interruption.

For administrators, setup begins with the SSO applications the company already has: Cursor or Claude Code, plus Figma. In Okta’s managed connections interface, the administrator permits one application to request access to another. Galow’s example allows Cursor to request access to Figma. When Cursor asks for a Figma ID-JAG, Okta can check that source-to-target policy before issuing it. The user must still belong to both applications; the connection policy does not replace application membership.

An MCP client needs an XAA-compatible SSO connection, with XAA enabled on the customer’s IdP connection. It must request an ID-JAG from that IdP, exchange the grant at the target authorization server, and then use the returned access token for ordinary MCP requests. Galow describes IdP support as new and still developing. He says WorkOS implements the SSO, grant-request, and exchange stages for client builders, and identifies Cursor and Anthropic as using that support through their WorkOS SSO connections.

For a company exposing an MCP server, the new work sits primarily in its authorization server:

1. Advertise support for the ID-JAG flow. Clients need to discover that the authorization server accepts the grant used by the ID-JAG flow.
2. Accept the assertion. Receive the ID-JAG through the token exchange request.
3. Validate it against the trusted IdP. Verify the signed JWT and its intended use using the relevant identity-provider trust information. Merely decoding a JWT is not validation.
4. Issue the access token. Only after successful validation should the authorization server return the ordinary credential used at the MCP resource server.

Galow describes verification as the familiar signed-JWT validation problem. His overview ends at this implementation boundary, directing builders to the specification and a technical blog for the detailed contract; he also suggests using Claude to help unpack the IETF terminology.

The first audience question asks whether the flow also solves authorization—for example, choosing among Figma token scopes. In the demonstrated experience, the user connects as themselves and retains the permissions Figma gives that user. Galow describes IdP-imposed permission caveats as further work under discussion. That limitation should be read as a boundary of the experience he presents: the historical draft already includes optional scope requests and IdP policy evaluation, so it is too broad to conclude that scopes are absent from the protocol altogether. The demo does not establish fine-grained Figma permission controls.

The next question is how a client knows which application to request inside Okta. Galow uses mcp.figma.com as a simplified audience example: the client knows the service it wants, and Okta maps that target to its Figma application. In the draft’s more precise terminology, audience identifies the resource authorization server by its issuer URL; a separate optional resource parameter identifies the protected resource. Implementations should preserve that distinction rather than automatically substituting an MCP hostname for the authorization-server audience.

Asked whether audience selection could be used to manipulate scopes, Galow says he does not think so. The audience selects the intended recipient; it does not itself define a permission set. Okta must recognize the target application, and Figma must validate the assertion for its intended audience through the trusted Okta relationship. Selecting a target is not a substitute for permission checks.

Asked about Microsoft Entra, Galow says it does not yet support XAA and that WorkOS is working with Microsoft on adoption. His availability report at the talk is Okta-only, with OIDC connections supported and SAML support planned. He describes a refresh token, ID token, or SAML assertion as possible proofs of the user’s application session; that initial proof is the part tied to the SSO connection type. Current Okta XAA documentation also describes SAML requesting applications, so the OIDC-only statement belongs to the recording’s deployment context.

An attendee then describes an Entra integration in which Claude Code, Codex, and Claude Desktop behave differently around resource parameters and scopes. They identify the flow as single sign-on and cite RFC 9728, OAuth 2.0 Protected Resource Metadata, while reporting that Entra rejects a resource/scope mismatch. RFC 9728 defines protected-resource discovery and identifier validation; it does not impose a general rule that resource and scope strings must be identical.

Galow does not diagnose that integration onstage. He confirms the governing constraint: requested OIDC scopes must fit what the server permits, and a mismatch must not cause the server to grant unauthorized scopes. The detailed client differences are left for an after-talk discussion, with no concrete fix established.

The attendee adds a registration problem: Entra lacks Dynamic Client Registration in their setup, leading them to use a proxy that recognizes incoming clients and adjusts headers before forwarding requests. Galow treats this as part of the ecosystem’s uneven protocol support. He describes DCR as widely supported among MCP clients and servers, but says an unsupported combination requires preregistering the client.

He closes with Client ID Metadata Documents, or CIMD, as a newer approach: clients publish their metadata upfront rather than requiring a new registration record each time. The November 2025 MCP authorization specification recommends this approach while retaining DCR and preregistration.

Galow presents CIMD as a better experience with less ecosystem support at the time, describing it as only a few months old. Its introduction does not remove DCR or make existing integrations interoperable automatically. XAA can eliminate repeated consent through shared enterprise trust, while discovery, scope handling, and client registration still require agreement between the systems on both ends.