XAA vs. ID-JAG vs. EMA: What's the Difference?

If you have been reading about how AI agents reach enterprise applications, you have probably seen three acronyms used in close quarters: XAA, ID-JAG, and EMA. They turn up in the same paragraph—sometimes the same sentence—and rarely with an explanation of how they relate.

They are three names for one capability, drawn from three different places: the name the ecosystem uses for the pattern, the IETF specification that defines the mechanism, and an extension to the Model Context Protocol that applies it. Knowing which of the three a term belongs to makes the rest of the conversation easier to follow, whether you are evaluating vendors, reading a specification, or deciding what to call the feature you are shipping.

What is Cross-App Access (XAA)?

Cross-App Access (XAA) is the common name for a pattern: one application reaches another application's APIs or MCP server on a user's behalf, brokered by the enterprise identity provider that both applications already trust.

The relationship between the pattern and its specification mirrors one already familiar in auth terminology: SSO and OIDC. Single sign-on (SSO) is what the capability is called, and OpenID Connect (OIDC) is one of the protocols that defines how it works. Cross-App Access is the capability, and the grant described in the next section (ID-JAG) is the underlying draft specification.

XAA reuses that SSO relationship so the identity provider (IdP) can also broker access between applications, rather than each pair of applications establishing its own connection through API keys or individual OAuth consent.

Two properties define it:

• The identity provider decides whether a given requesting application may reach a given resource application, and with which scopes, based on policy the enterprise controls centrally.

• The resource application's authorization server still issues its own access tokens and applies its own local policy, so the identity provider brokers the relationship without taking over authorization.

How Cross-App Access (XAA) works

Three parties take part in a standard XAA flow: the requesting app (an AI agent or MCP client), the enterprise identity provider, and the resource app that owns the API or MCP server. On the resource app's side of the exchange, the work is handled by its authorization server (the same component that already issues its access tokens).

1. The user authenticates with the IdP through SSO and receives an ID token.

2. The requesting app exchanges that ID token at the IdP's token endpoint, asking for access to a specific resource app.

3. The IdP evaluates the request against enterprise policy, checking whether this requesting app may reach that resource app with the scopes requested.

4. If the request is allowed, the IdP returns a signed assertion scoped to that resource app.

5. The requesting app presents the assertion to the resource app's authorization server.

6. The resource app validates the signature against the IdP's public keys and issues a short-lived access token.

7. The requesting app calls the API with that access token until it expires.

What is ID-JAG?

ID-JAG stands for Identity Assertion JWT Authorization Grant. It is the IETF draft specification that defines the token exchange in step 2 above, and the assertion that comes back in step 4. It also names the assertion itself, which is why you will see the term used for both the document and the token.

It is an Internet-Draft on the IETF standards track, at draft 04 as of May 2026, rather than a published RFC. The specification profiles Identity Chaining Across Trust Domains, which in turn combines two established standards:

• OAuth 2.0 Token Exchange governs how the requesting app trades its ID token for an assertion at the IdP.

• The JWT Bearer grant governs how the requesting app redeems that assertion for an access token at the resource app.

What's inside an ID-JAG

An ID-JAG is a signed JSON Web Token (JWT) with a short lifetime, issued for one specific downstream authorization server. Its typ header (the token type declaration) must be oauth-id-jag+jwt, which lets a resource authorization server reject anything that was minted for a different purpose.

Here is a (non-runnable) example payload:

{
  "typ": "oauth-id-jag+jwt"
}
.
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://idp.example.com/",
  "sub": "user_8f2c41",
  "aud": "https://auth.resourceapp.example/",
  "client_id": "agent_a91b7",
  "iat": 1789012045,
  "exp": 1789012345,
  "resource": "https://mcp.resourceapp.example/mcp",
  "scope": "read:tickets write:comments",
  "auth_time": 1311280970,
  "amr": [
    "mfa",
    "phrh",
    "hwk",
    "user"
  ]
}
.
signature

There are many claims here, but the ones that matter most from a security standpoint are aud, resource, client_id, scope, and sub.

Of these, the claim implementers most often get wrong is aud (the audience claim). It names the issuer identifier of the resource authorization server, not the API or MCP server being reached. The protected resource is named separately by resource (the resource indicator). It's an important distinction because, as soon as one authorization server governs several resources (the typical trajectory for a SaaS product), audience and resource claims can't meaningfully be treated as the same thing:

• aud identifies the authorization server that should process the ID-JAG.

• resource identifies the particular resource for which authorization is being requested.

Think of the audience claim as a boundary where the identity provider's authority ends. It can say "this client is allowed to deal with that authorization server on this user's behalf within these specific parameters." That user is the sub (the subject claim) and the parameters are the scope (the permissions the IdP is willing to vouch for), which means they shape requests inside the boundary that the vendor then narrows or refuses. And, crucially, because aud names a single authorization server, an assertion minted for one destination cannot be presented at another; the draft specification calls this out as preventing "audience injection."

An ID-JAG is not an access token. It is an input to the resource application's authorization decision. The resource authorization server validates it and then issues its own token, which is the credential that actually reaches the API. The assertion says who the user is and what the identity provider is prepared to authorize; the resource authorization server decides what it will actually grant.

What is Enterprise-Managed Authorization (EMA)?

Enterprise-Managed Authorization (EMA) is an extension to the Model Context Protocol (MCP) that lets an administrator centrally authorize which MCP clients may reach which MCP servers, so users find those servers connected at first sign-in rather than authorizing each one themselves. The MCP maintainers announced the extension as stable in June 2026.

Under the hood, EMA uses the XAA pattern and the ID-JAG grant to do it. The MCP client obtains an assertion from the enterprise identity provider during sign-in and exchanges it for an access token at the MCP server's authorization server, which is the same sequence described earlier.

How EMA fits into the MCP specification

MCP already had an authorization specification covering OAuth 2.1, Client ID Metadata Document (CIMD) and Dynamic Client Registration (DCR), and Protected Resource Metadata (PRM). EMA covers the case where an enterprise, rather than an individual user, decides what an MCP client may reach.

It does that as an extension rather than as part of the core protocol. The 2026-07-28 specification introduced a formal extensions framework, and capabilities that ship there are additive and opt-in: an MCP server advertises support as a capability and the client negotiates it at connection time. Per-user OAuth remains the default for servers that have not adopted it.

What EMA does not cover

EMA is a connection-level control. It settles whether a given user's client may reach a given server, and at what scope, at the moment the token is issued. It does not follow the session after that.

The identity provider evaluates policy once, when it mints the grant, and issues nothing afterward. What the MCP server sees on each subsequent request is the access token from its own authorization server, so enforcement of what an agent does inside an approved connection belongs to the resource server and the scopes it honors. Seeing "the enterprise authorized this connection" and thinking "this session is properly governed" is the reason EMA belongs alongside per-tool scoping (not in place of it).

XAA vs. ID-JAG vs. EMA: key differences

Why the three terms get used interchangeably

Each name entered the conversation from a different direction. XAA names the pattern, and spread because the industry needed a word for it. ID-JAG arrived through the IETF as the specification that made the pattern concrete and interoperable. EMA came from the MCP community, which needed a name for the capability inside the context of the protocol.

The three also arrived close together. ID-JAG became an IETF OAuth working group document in 2025 and EMA reached stable status in June 2026, and a single announcement often touches all three at once, so writers reach for whichever name fits the sentence.

That is usually harmless. It becomes a problem when a reader concludes they need to choose among them, or when a security review asks which one a product supports and gets an answer at the wrong layer.

How the three fit together

Consider an AI assistant that needs to read a user's tickets from a vendor's MCP server. A single request touches all three terms:

• The enterprise administrator has approved this assistant to reach that MCP server, and users find it already connected when they sign in. That is Enterprise-Managed Authorization: the capability, from the administrator's point of view.

• The assistant obtains authorization from the enterprise identity provider rather than from a separate consent screen at the vendor, and the vendor's authorization server still decides what to grant. That is Cross-App Access: the pattern.

• The assistant exchanges its ID token for a signed assertion audienced to the vendor's authorization server, and redeems it there for an access token. That is ID-JAG: the mechanism.

Each name is accurate for the part of the picture it describes. The confusion comes from using one where another belongs, and the terms are not interchangeable: a product can implement the grant without adopting the MCP extension.

Which term to use when

Follow these rules of thumb to cover most situations:

• Use Enterprise-Managed Authorization when the audience is an administrator or a buyer and the subject is what the enterprise can control inside MCP. It is also the correct term for the extension itself.

• Use Cross-App Access when the subject is how applications establish trust with each other through an identity provider, particularly outside an MCP context. The pattern applies to any case where one application acts for a user in another application, not only to AI agents.

• Use ID-JAG when the subject is the exchange itself: token endpoints, claims, signatures, and validation. This is the term for engineering conversations and implementation work, and the correct name for the assertion.

Atlassian has published an account of implementing EMA for Rovo MCP that walks through the same distinctions from an implementer's side.

Cross-App Access with Descope

Both halves of the exchange need an implementation before any of this works in production. The identity provider has to mint assertions, and the resource authorization server has to validate them and issue its own tokens. The Descope Agentic Identity Hub supports both.

• Validating ID-JAG assertions, so a company selling an MCP server can register each enterprise customer's identity provider as a trusted issuer scoped to that customer's tenant. Descope validates the assertion and issues a standard access token, so the MCP server itself needs no ID-JAG handling.

• Issuing ID-JAG assertions, so an organization's own agents can reach any other MCP server or API under policies evaluated on each request.

• Self-service Cross-App Access setup in the SSO Setup Suite, where a customer's administrators configure it themselves alongside SSO, SCIM, and JIT provisioning rather than filing a ticket with your team.

Descope also covers the surrounding MCP authorization work these assertions plug into, including OAuth 2.1 and PKCE, CIMD and DCR, consent management, and per-agent and per-tool scopes.

Getting started with XAA, EMA, and ID-JAG

The three terms will keep appearing together, because the capability they describe is being adopted in three places at once: a specification moving through the IETF, a protocol extension stabilizing in MCP, and products shipping the pattern to enterprise buyers. Knowing which name belongs where is what keeps a vendor evaluation, a specification review, and a roadmap conversation from talking past each other.

Sign up for a Free Forever account with Descope and start building secure, scalable auth flows for your agents and MCP servers. Have questions about Cross-App Access, ID-JAG, or EMA? Book time with our experts.

FAQs about XAA, ID-JAG, and EMA