Cross App Access (XAA): The enterprise way to govern AI app integrations

AI apps are becoming the new universal remote for work. They connect to project trackers, CRMs, ticketing systems, docs, data warehouses, and whatever else your users point them at. That’s powerful, but also a compliance headache.

Until recently, when a user connected an MCP client (say, an AI app) to an MCP server (say, Asana, Zendesk, or any tool exposing MCP), the OAuth handshake happened directly between those two apps. The corporate IdP mostly saw “Eric signed into Asana,” not “an AI app can now act as Eric in Asana.”

That gap is the shadow IT problem in neon lights:

• Admins can’t easily answer which AI apps have access to what tools.
• They can’t see what scopes those apps have or what they can do.
• And they can’t revoke access centrally without hunting through every downstream app.

Cross App Access (XAA) fixes this by inserting the enterprise IdP back into the loop for app-to-app OAuth. It’s built on the IETF Identity Assertion Authorization Grant spec, and it’s the foundation for MCP’s enterprise-managed authorization extension. The result: centralized admin control without new consent popups or user friction.

This post is a deep dive into what XAA is, why it matters now (especially for AI agents), and how the flow works end-to-end.

The problem XAA solves: Invisible delegation

Traditional OAuth delegation is user-centric:

1. User clicks “Connect to Asana.”
2. AI app and Asana run OAuth directly.
3. Asana issues tokens that let the AI app act as the user.

From the IdP’s perspective, step 2 and 3 are mostly invisible. The IdP may have authenticated the user to Asana, but it didn’t authorize the relationship between the AI app and Asana.

That means the enterprise loses its usual control plane:

• No policy gate before delegation happens.
• No normalized audit trail of cross-app grants.
• No single revocation lever.

In an MCP world, where AI clients may connect to many MCP servers across a company, this becomes consent-and-governance chaos fast.

What is Cross App Access (XAA)?

Cross App Access (XAA) is an OAuth 2.0 extension that lets an enterprise IdP manage and approve connections between two apps. Instead of OAuth happening only between an MCP client (AI app) and an MCP server (tool), XAA makes the IdP a first-class decision-maker in that relationship.

This model just became a formal part of MCP. In the 2025-11-25 MCP spec, XAA was introduced as one of the first Authorization Extensions (SEP-990), specifically to address enterprise shadow-IT and visibility gaps in AI-to-tool delegation. Put simply: MCP now has a standardized, IdP-in-the-loop path for enterprise-governed user access alongside its other OAuth improvements.

With XAA enabled, the high-level flow becomes:

1. User signs into MCP client with SSO
2. MCP client performs token exchange with the IdP
3. IdP enforces allowlists/policy and issues a short-lived assertion
4. Client swaps that assertion for an MCP access token at the MCP server
5. No extra consent popups

Think of it as “SSO-level governance for app-to-app delegation.” Same trust fabric, now applied to cross-app access.

Identity Assertion JWT Authorization Grant: The OAuth specification powering XAA

The standard underneath Cross App Access is the Identity Assertion JWT Authorization Grant, often shortened to ID-JAG.

In normal OAuth, an app gets an access token either because a user clicked through consent, or because the app already has its own credentials (like a client secret). ID-JAG adds a third option: the enterprise IdP can issue a special, short-lived JWT that asserts “this client is allowed to act for this user at that downstream app.”

Concretely, after a user signs into an MCP client with SSO, the client asks the IdP for an identity assertion targeted at a specific resource app (the MCP server). The IdP evaluates admin policy and, if allowed, returns a signed JWT whose key properties are:

• It’s audience-bound to the downstream app (so it can’t be replayed elsewhere).
• It names the user, the client, and the approved scopes/resources.
• It expires quickly.

That JWT is not yet an access token. It’s more like a notarized permission slip from the IdP. The client then presents this assertion to the downstream MCP server using a JWT-bearer style grant, and the MCP server (because it already trusts the IdP’s signing keys from SSO) can validate the assertion and mint a normal OAuth access token.

ID-JAG and XAA: spec name vs. ecosystem name

You’ll notice two terms floating around for the same core idea, and it can feel a bit like the “band vs. the genre” problem. Identity Assertion JWT Authorization Grant (ID-JAG) is the actual OAuth extension being standardized at the IETF. It’s the technical blueprint: how an IdP issues a signed identity assertion, what claims it must contain, and how a client redeems it at a downstream authorization server. Because it’s an open standard, any IdP can implement ID-JAG and any SaaS platform can choose to support it.

Cross App Access (XAA), on the other hand, is the name most people encounter in the wild. That’s largely because Okta has been a major driver of both the spec and early adoption, and they use “XAA” as the product umbrella for their implementation. The branding is sticky: it’s shorter, more descriptive at first glance, and (let’s be honest) easier to say in a meeting than “Identity Assertion JWT Authorization Grant.”

So in practice, “XAA” is becoming shorthand for the whole extension, even though the underlying mechanism is ID-JAG and remains vendor-neutral. It’s worth giving Okta credit for pushing the work forward, but also worth keeping the distinction clear: XAA is one implementation and ecosystem label, while ID-JAG is the interoperable spec that anyone can adopt.

How the XAA flow works

The flow has three parties:

• An MCP client (the AI app)
• An Enterprise IdP (Okta/Entra/etc.)
• An MCP server (downstream tool/resource)

The happy path looks like this:

1. User signs into the MCP client via SSO: Normal OIDC login: the user authenticates to the enterprise IdP (Okta/Entra/etc.) and the MCP client receives an ID token.
2. Client requests cross-app access via token exchange: The MCP client calls the IdP’s token endpoint using OAuth Token Exchange and says, essentially: “Given this user session, I want access to that MCP server.” Importantly, it’s asking for an ID-JAG identity assertion, not a resource access token yet.
3. IdP applies enterprise admin policy: The IdP evaluates the request using the org’s configured rules, just like it would for SSO access. Policies can cover both which clients may connect to which servers and what they’re allowed to do once connected. Example checks:
   
   1. Is this MCP client allowed to connect to this MCP server at all? (app-to-app allowlist / denylist)
   2. Are the requested scopes allowed? (least privilege enforcement)
   3. Should this require step-up auth? (MFA or higher trust if access is sensitive)
   4. Is the user in an allowlisted group? (role/group-based gating)
4. IdP issues a short-lived identity assertion (ID-JAG): If policy passes, the IdP returns a signed JWT assertion targeted at the MCP server (audience-bound so it can’t be reused elsewhere). Think of this as the IdP saying: “We approve this client acting for this user at this server, with these scopes, until this expiry.” It’s a permission slip, not the final access token.
5. Client presents the assertion to the MCP server:The MCP client sends that assertion to the MCP server’s token endpoint using a JWT-bearer-style grant. The MCP server validates the signature and claims against the IdP’s JWKS and metadata (the same trust it already uses for SSO logins).
6. Client uses the MCP access token to call the MCP server: Once validated, the MCP server issues a normal short-lived MCP access token, scoped to what the IdP approved, and the client can start making API calls. When that access token expires, the client repeats the exchange or redemption flow, so long-lived standing privileges never accumulate silently.

This way, admins get centralized control and visibility, users don’t see another consent screen, and AI apps don’t hoard long-lived secrets. Everybody wins.

Why this matters to enterprise IT admins

XAA turns a fuzzy, app-local delegation problem into a crisp, IdP-managed one.

Admins gain:

• Visibility into AI-to-tool delegation: The IdP can log and surface “Client X has access to Server Y as User Z with scopes A/B/C.”
• Centralized approvals and blocklists: Allow safe MCP clients to connect to approved tools by default. Block risky pairings before any token exists.
• One-click revocation: Kill a client’s downstream access at the IdP and the assertion path dries up everywhere.
• No consent fatigue: Users authenticate once to the MCP client. After that, access decisions are admin policy, not user popups.
• Cleaner audits and compliance posture: Delegation is explicit, attributable, and policy-backed, rather than implied by scattered OAuth grants inside tools.

This is the core reason XAA was added to MCP. It closes the governance loop for cross-app AI access.

Why this matters to SaaS builders

XAA is the enterprise-friendly way to let your app connect to AI agents and MCP servers.

Supporting XAA means:

• You can rely on enterprise policy instead of per-user consent. Without XAA, every user has to individually authorize every AI app in your product, and you have no idea whether the enterprise is OK with that pairing. With XAA, the IdP becomes the approval gate, so when an MCP client shows up with an assertion you know it’s enterprise-sanctioned, not a random end-user experiment. That reduces “surprise integrations” and makes your OAuth model align with procurement reality.
• You get cleaner, more predictable enterprise rollouts. Enterprise deployments often fail on “last mile” friction: too many consent prompts, unclear admin controls, and inconsistent setup across thousands of users. XAA lets admins pre-approve AI clients and scopes once in the IdP, so users don’t hit a consent wall on day one. Result: faster adoption, fewer rollout tickets, and less need for you to build bespoke “enterprise admin approval UIs” inside your own product.
• You reduce support burden around revocation and audits. Today, when a security team asks “which AI apps can access our data in your product?” you’re stuck pointing them to per-user OAuth grants or scattered logs. With XAA, revocation and inventory live centrally at the IdP, and your org customers can answer those questions without opening a support case. From your side, it means fewer escalations like “please purge tokens for this AI vendor across our tenant.”
• You avoid long-lived secrets and lower your risk profile. A lot of AI integrations still fall back to API keys or durable refresh tokens because they need non-interactive access. That’s risky for you and your customers: secrets leak, refresh tokens linger, scopes drift. XAA keeps credentials short-lived and re-issuable under policy, so the blast radius stays small and there’s a clear enterprise kill switch if something goes wrong.
• You fit into modern enterprise buying criteria. When enterprises evaluate AI and MCP integrations now, “can we govern it in Okta/Entra?” is quickly becoming a gating question. If your MCP server supports XAA, you can confidently say: “Yes, your IdP decides which AI clients can connect, which scopes they can request, and you can revoke centrally.” That’s a competitive advantage in security reviews and procurement cycles.
• You’re building on a standard, not a one-off vendor feature. Even though “XAA” is the common name, the underlying mechanism is the ID-JAG spec. Supporting it positions you for interoperability as more IdPs ship compatible flows, and avoids locking your enterprise story to any single vendor’s proprietary scheme.

XAA makes MCP integrations enterprise-deployable at scale. It shifts the approval and governance surface to the IdP, which is where enterprise customers already expect it, while letting your product remain a clean, standards-based resource server.

What builders need to know

A few details from the draft spec are worth calling out for implementers:

• XAA is for confidential clients. The ID-JAG flow assumes the requesting app can authenticate to the IdP securely (for example with a client secret or private-key JWT). That’s why it’s targeted at server-side or otherwise “confidential” clients, not pure browser or mobile public clients, since the IdP is issuing a high-trust assertion that could be redeemed for downstream access.
• Audience and client_id mapping matter. The IdP has to mint an assertion that the downstream authorization server (MCP server) will accept, so the aud claim must point at that server’s issuer, and the client_id has to be meaningful in the resource app’s domain. The draft discusses cross-domain client identity and points to ‍ as a standardized way to avoid brittle, per-pair mapping tables.
• It’s intentionally cross-domain. The model is designed for a “shared enterprise IdP, different app domains” situation, where the IdP mediates trust between two independent apps. As a result, the IdP shouldn’t mint an ID-JAG to obtain access tokens for resources it controls itself; the whole point is enabling interoperable, app-to-app authorization across domains, with the IdP as the neutral policy hub.
• Your resource server must validate the assertion like an enterprise artifact. MCP servers need to verify the ID-JAG’s signature using the IdP’s JWKS and enforce the required claims (typ, aud, expiry, scopes/resources). In other words, treat the assertion the way you’d treat an OIDC ID token from an enterprise SSO connection, because that’s the trust anchor XAA is extending. For more on JWT validation, see JWT validation: How-to and best libraries to use.

WorkOS for MCP auth

If you’re building an MCP server that needs auth, WorkOS basically exists to save you from re-implementing OAuth edge cases. AuthKit works as an OAuth 2.1–compatible authorization server for MCP, aligned with the latest spec, so you can secure tools/resources with minimal protocol glue.

What this looks like in practice:

• If you are already running user auth, use WorkOS Connect as an OAuth bridge: MCP clients authenticate through WorkOS, users sign in to your app, and WorkOS issues tokens that the MCP client can use with your MCP server. This is how Mux launched its MCP server quickly without rebuilding auth. For more details, see our docs.
• If you don’t want to run user auth (as you should), use AuthKit for all your logins: users, AI agents, MCP clients, and servers. WorkOS AuthKit handles all the complexity of the OAuth Authorization Server. You just build the MCP tools and resource endpoints. For more details, see our docs.
• Map OAuth scopes to internal roles and permissions using WorkOS RBAC. Each access token your MCP server receives will include the granted permissions so you can enforce least-privilege access.
• Use WorkOS Audit Logs to see what your users, agents, and MCP clients did, when, and on whose behalf. Get enterprise-grade compliance and stream logs to your customer’s existing SIEM provider effortlessly.

MCP gives agents reach. WorkOS helps you decide who gets that reach, to what, and under what rules.

Closing thoughts

Cross App Access is one of those standards that feels inevitable once you see the shape of the problem. Enterprises are done with invisible, user-scattered integration grants and permanent secrets. AI agents just sped up the deadline.

XAA brings app-to-app connectivity under the same enterprise governance umbrella as SSO: centrally approved, policy-enforced, short-lived, and auditable. It’s the OAuth model the next decade of software needs.