Table of Contents
Don't have the time to read the entire post? Our human writers will be sad, but we understand. Summarize the post with your preferred LLM here instead.
To do their jobs properly, enterprise applications need to talk to each other: project management tools pull data from CRMs, a CI/CD pipeline pushes to a code repository, an analytics dashboard queries multiple SaaS APIs.
These connections have traditionally relied on one of two approaches:
Long-lived API keys that never expire, or
OAuth flows that require manual user approval for every integration
Both scale poorly, which is why Cross-App Access (XAA) is gaining traction, particularly for agentic AI use cases.
In simplest terms, XAA extends enterprise SSO to APIs. Just as your identity provider (IdP) manages who can log in to which applications, XAA lets that same IdP manage which applications can reach other applications' APIs on behalf of users.
You'll also see the underlying specification called the Identity Assertion JWT Authorization Grant, or ID-JAG. The two terms sit at different layers: ID-JAG is the IETF document that defines the token exchange, and Cross-App Access is what the industry calls the pattern that document enables. The specification itself draws the same line, noting that the pattern it describes is informally referred to as Cross-App Access.
In the following post, we'll walk through the problem XAA solves, how it works, where the standard currently stands, and what it changes for AI agents.
The problem with API keys and OAuth consent flows
The two traditional approaches for app-to-app access struggle at scale, though each has its own specific challenges.
API keys
API keys are essentially a password that an application uses to authenticate with an API, or Application Programming Interface. This is a layer that enables different apps to communicate even if they’re written in different languages.
When App A needs to access App B’s API, App B generates a key (usually a quite long random string) that App A includes with every API request. That API validates the key and grants access.
The problem is how these keys are managed in actual practice. Most API keys are:
Long-lived (meaning they don’t expire unless manually revoked)
Over-scoped (they have broad access rather than permissions for only what’s essential)
Decentralized (spread out across config files, environment variables, local machines, etc.)
This is why when an API key leaks (and they often do), enterprises face huge security liabilities. With no centralized inventory of which systems hold keys to what resources, and no automatic expiration or rotation, revocation usually requires coordination across teams to limit damage. Meanwhile, keys are often stored across multiple services, making selective revocation impossible without potentially breaking production.
While you can implement key rotation, scoping, and centralized management of API keys, most organizations struggle to do this consistently across their many, many applications. And most simply choose not to, because it isn’t built-in, and they have other priorities.
OAuth consent flows
OAuth consent flows, which are a core part of the Open Authorization (OAuth) specification, address some of the API key issues by introducing time-limited access tokens and user-controlled permissions. Instead of App A holding a permanent key to App B, the flow works like this:
App A redirects the user to App B’s authorization server
User logs in and sees a consent screen: “App A wants to access your calendar data”
The user approves, and App B issues an access token with specific scopes and an expiration for App A
App A uses this token to make API calls
This is obviously much more secure than API keys: It handles the long-lived access problem, tackles the trouble with over-scoping (assuming the app doesn’t request outlandish scopes), and adds some user-facing elements for some (but limited) visibility into what’s going on.
The real challenge arises at enterprise scale, when you’re dealing with hundreds of apps, thousands of users, and the need to enforce non-negotiable security policy across all of it. Below are just a few of the struggles organizations face when using OAuth consent flows for app-to-app API access at scale:
User experience friction: Because each integration takes a separate OAuth flow, a new employee connecting Slack, Trello, Google Calendar, Salesforce, HubSpot, and GitHub might click through a dozen consent screens before they can even start working. Multiply this across every employee and every app integration.
IT visibility is limited: These OAuth connections happen directly between the user and the apps, meaning IT is out of the loop by default. When an employee authorizes “Generic Marketing Analytics Tool #43” to access sensitive customer data in Salesforce, IT/InfoSec has no centralized view of that happening. The authorization lives in the Salesforce settings for that user.
Fragmented access management: While not buried as deep (or in such varied places) as API keys, revocation still requires security teams to log into each resource app individually, find the authorized connections, and disable them. There’s no built-in visibility that shows “which apps can access what data across our organization.”
Policy gaps: IT/InfoSec can’t pre-approve safe integrations or block risky ones. Every authorization decision happens at the user level, in the moment, without organizational policy enforcement until after the fact.
For enterprise use cases, the recurring issue between both of these approaches is that there’s no unified governance layer to revoke access, observe connections, and enforce policy.
What enterprises need is:
Centralized visibility into all app-to-app connections
Policy-based access control managed by security teams, not individual users
Short-lived credentials that expire automatically
Audit trails that show which app access what data, and when
The ability to revoke access instantly from a single point of control
These are the problems that ID-JAG/XAA was designed to solve.
How Cross-App Access (XAA) works
In a nutshell, XAA extends enterprise SSO patterns to app APIs. It lets IdPs govern which applications can access other applications' APIs, with enforcement that supersedes the user level.
It may sound quite similar to the OAuth consent flow, but with observability and policy baked in, and there's a good reason for that: it's based on the same underlying standards. The key difference is that instead of apps establishing direct trust with each other, the enterprise IdP mediates every connection. IT/InfoSec can pre-approve (or pre-deny) which integrations are allowed, and the IdP issues short-lived, scoped tokens only when policy permits.
OIDC and keys
XAA invokes the IdP's existing private key that it uses to sign JWTs, or JSON Web Tokens. The IdP publishes its public key so other entities, like resource apps, can verify that its signature on a JWT is legitimate. This is the same signing mechanism used in standard OpenID Connect (OIDC) ID tokens. The resource app already trusts the IdP for SSO, fetching its public keys to validate ID tokens, and XAA builds directly on that relationship.
The XAA flow
The protocol involves three parties: the requesting app (the one that needs API access), the resource app (the one that owns the API or MCP server), and the enterprise IdP (which governs and mediates the connection).
Here's how the token exchange works:
The user authenticates with the IdP via SSO, receiving an ID token (as in a standard OIDC flow).
The requesting app requests exchange of the ID token for an ID-JAG at the IdP's token endpoint as per RFC 8693 token exchange.
The IdP validates the request against company policy: Is the requesting app allowed to access this resource app? Are these scopes permitted for this user?
If approved, the IdP issues an ID-JAG (a signed JWT) back to the requesting application.
The requesting app presents the ID-JAG to the resource app's authorization server using the JWT bearer grant type (RFC 7523).
The resource app validates the ID-JAG signature using the IdP's public keys (the same JWKS, or JSON Web Key Set, used for OIDC), then issues a short-lived access token.
The requesting app makes API calls with the access token until it expires (typically within 10-15 minutes).
One quick note on what the resource app actually keeps: the spec very intentionally leaves the resource authorization server as the issuer of access tokens for its own protected resources. The IdP vouches for the user, but it doesn't mint credentials on the resource app's behalf.
The difference between XAA and ID-JAG
The terms "XAA" and "ID-JAG" have often been used interchangeably, and in most conversations that's fine. Everyone generally understands what you mean if you say one or the other. The terms sit at different layers, though, and the distinction has become increasingly meaningful.
The division of ID-JAG vs. XAA is similar to how the industry talks about single sign-on (SSO). SSO is the broader pattern, while OIDC and SAML are the specifications underneath. In a similar vein, XAA is the "what," and "ID-JAG" is the "how."
ID-JAG: The Identity Assertion JWT Authorization Grant is an OAuth extension moving through the IETF Web Authorization Protocol working group on the standards track. It defines exactly how an identity provider issues an assertion that an application can exchange for an access token. It's worth remembering that's the name of the token itself, too: an IdP issues an ID-JAG.
XAA: The published ID-JAG draft notes that the pattern it defines is informally referred to as Cross-App Access. While the spec's authors come from several different identity vendors, the XAA name has decoupled from any single product or service.
In June 2026, the Model Context Protocol (MCP) officially adopted the grant as its Enterprise-Managed Authorization (EMA) extension, and it's since seen adoption by Anthropic, Microsoft, and a growing number of MCP builders.
However, this inserts a third name for roughly the same mechanics, though it's bound to the MCP ecosystem. The simplest explanation goes like this: the MCP extension is EMA, XAA is the broader term for the pattern EMA uses, and ID-JAG is the spec that underlies both.
Why AI is driving XAA adoption
While XAA solves long-standing enterprise problems in app-to-app connections, AI agents are what made a solution urgent rather than a luxury.
An agent that needs to check your calendar, create a Zoom meeting, update a project tracker like Trello, and send a Slack notification faces constraints that traditional applications simply don't. The agent can't pause its workflow to complete OAuth consent screens, and it can't safely hold semi-permanent API keys to every system it might need to access.
The industry best practice is treating agents like first-class identities. They should have their own discrete, ephemeral credentials bound to a specific user and task, which die when the task is done. But organizations are slow to keep up with agentic identity demands. 2026 research from Gravitee found that only 22% of teams treat agents as independent identities, with most still relying on shared API keys. XAA (or more specifically for MCP, EMA) provides a standards-defined way for enterprises to centralize agent governance at scale. While the MCP extension is far from a "plug and play" experience, it's much more closely aligned with industry consensus than hand-rolled scaffolding. Read more: AI Agent Credential Management Best Practices
Traditional approaches to agentic app-to-app access
We’ve seen several approaches to resolving this issue for agents:
API keys, as previously mentioned, can’t be trusted with agents. Agents are still too unpredictable for them to hold these typically overscoped credentials.
OAuth consent flows are a step up, but aren’t viable for workflows where agents might need to talk with dozens of applications: “I need you to approve Slack…now Zoom… now Asana…” defeats the value of many agentic scenarios.
Service accounts with broad access have seen use by some organizations, giving dedicated access rights to the agent. Except this invites a new problem: The agent operates with its own fixed identity that isn’t tied to the user making requests. This is obviously less than ideal for visibility.
How ID-JAG/XAA helps AI agents connect with apps
With XAA, an AI agent requests tokens through the enterprise IdP on demand, rather than holding a persistent set of credentials. When the agent needs to access Salesforce, for example, it exchanges its ID token (from when the user authenticated with SSO) for a scoped, short-lived token that permits only the specific capabilities needed for the task at hand.
The token expires automatically, the request is logged and traceable back to both the user and the agent, and IT/InfoSec maintains policy control over which agents can access which resources. This dovetails neatly with how enterprises actually think about agentic security: agents should act on behalf of users, with permissions derived from those users' access rights, not operate as independent, un-monitorable entities with overly broad scopes.
IT/InfoSec can define policies covering which types of agents reach which types of apps and what their permissions are within those environments: reading calendars but not writing to them, adding meetings for Zoom but not Google, and so on. These policies are enforced at the IdP level rather than requiring each application to implement its own agent auth logic for every possible interaction.
Where MCP fits in with XAA
Most of this now plays out through MCP servers. When a B2B company exposes an MCP server to its customers, those customers' security teams want to govern agent access with the identity provider they already run. Enterprise-Managed Authorization is the MCP extension that makes that possible, and XAA is how it works underneath: the customer's IdP mints an assertion, the MCP server's authorization server redeems it for an access token, and no one clicks a second consent screen.
Securing and simplifying app-to-app access
Cross-App Access extends enterprise SSO to API access, replacing unscalable static credentials and fragmented OAuth flows with IdP-mediated, short-lived tokens. The problem it addresses predates agentic AI by years across SaaS integrations of every kind, but AI agents are what turned the problem from a tolerable annoyance into an urgent need.
Descope supports both sides of the exchange in the Agentic Identity Hub:
A company selling an MCP server can register a trusted issuer for each tenant, so an assertion minted for one customer cannot be redeemed against another. Per-organization scope policies determine what level of agent access each customer receives, and the MCP server itself never has to implement ID-JAG.
An organization running its own agents can register each downstream MCP server or API as a Resource and writes a token exchange policy that is evaluated on every request rather than baked into a long-lived credential.
Cross-App Access also lives in the SSO Setup Suite alongside SSO, SCIM, and JIT provisioning, so your tenant admins can configure it themselves without needing hands-on support.
If you're building AI agents, or apps that need to talk with them, the Cross-App Access developer playground walks through a full exchange end to end. You can also join AuthTown, our dev community, or sign up for a Free Forever Descope account to try the flow in your own project.
