# ID-JAG and Cross App Access (XAA)

Source: https://startwithidentity.com/standards/id-jag-cross-app-access/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

## What it is

The Identity Assertion JWT Authorization Grant (ID-JAG) is an IETF OAuth draft that lets an application get an access token for another application's API, on a user's behalf, by going through the enterprise identity provider (IdP) that both applications already trust for single sign-on. Its abstract says the pattern "is informally referred to as Cross-App Access (XAA)". The point is to move the "should app A reach app B's data for this user" decision away from an end-user consent screen and into IdP policy that an administrator controls, can audit, and can revoke centrally.

ID-JAG combines two published RFCs. [OAuth 2.0 Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693.html) is used to get the grant from the IdP, and the [JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523)](https://www.rfc-editor.org/rfc/rfc7523.html) is used to redeem it at the target. The token is a signed JWT with the header `typ` value `oauth-id-jag+jwt`, so it cannot be confused with an ID token. For the short definition see the glossary entries for [ID-JAG](https://startwithidentity.com/glossary/id-jag/) and [Cross App Access](https://startwithidentity.com/glossary/cross-app-access/).

## Status (November 2026)

The latest revision is [draft-ietf-oauth-identity-assertion-authz-grant-06](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/), dated 31 October 2026, read from the IETF datatracker on 5 November 2026. Its stream state is **WG Document**: the OAuth Working Group has adopted it, but it has not been through working-group last call, IESG review, or publication. The intended status is Standards Track. The editors are Aaron Parecki ([Okta](https://startwithidentity.com/vendors/iam/okta/)), Karl McGuinness (independent) and [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/) ([Ping Identity](https://startwithidentity.com/vendors/iam/ping-identity/)).

The work started as the individual draft draft-parecki-oauth-identity-assertion-authz-grant and was replaced by the working-group draft in August 2025, as recorded in SWI's [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/). Treat it as a pinned dependency: field names and processing rules can still change. The MCP extension that uses it, for example, still links to revision -04.

## How it works

The draft names four roles: the **client** (the requesting app or agent host), the **IdP Authorization Server** (the enterprise IdP), the **Resource Authorization Server** (the target app's OAuth server) and the **resource server** (the target API). A concrete flow, using a chat app that wants to read a user's tickets in a ticketing app:

1. **SSO.** The user signs in to the chat app through the corporate IdP with [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) or [SAML](https://startwithidentity.com/standards/saml-2-0/). The chat app now holds an ID token (or, for SAML, exchanges the assertion for a refresh token first).
2. **Token exchange at the IdP.** The chat app calls the IdP's token endpoint with `grant_type=urn:ietf:params:oauth:grant-type:token-exchange`, `requested_token_type=urn:ietf:params:oauth:token-type:id-jag`, the ticketing app's authorization server as the single `audience`, the ticketing API as `resource` ([RFC 8707](https://startwithidentity.com/glossary/resource-indicators/)), the wanted `scope`, and the ID token as `subject_token`. The client authenticates itself, for example with a JWT client assertion.
3. **IdP policy.** The IdP checks whether this client may act for this user at this audience with these scopes. If yes, it returns a short-lived ID-JAG. The MCP profile's example response has `expires_in` of 300 seconds.
4. **Redeem at the target.** The chat app posts the ID-JAG to the ticketing app's token endpoint with `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer` and authenticates with its credentials at that server.
5. **Local policy and token.** The ticketing app's authorization server validates the signature against the IdP's published keys, checks `aud`, `exp`, `jti` and `client_id`, maps `sub` to a local user through its existing SSO relationship, applies its own policy, and issues an access token.

The ID-JAG claims set is small. Required: `iss`, `sub`, `aud`, `client_id`, `jti`, `exp`, `iat`. Optional: `resource`, `scope`, `authorization_details` ([Rich Authorization Requests](https://startwithidentity.com/glossary/rich-authorization-requests/)), `act` (the RFC 8693 actor claim), `tenant`, `auth_time`, `acr` and `amr`. Note that `client_id` is the client's identifier at the target, which may differ from its identifier at the IdP.

Discovery is metadata-driven. An IdP advertises support by listing `urn:ietf:params:oauth:token-type:id-jag` in `identity_chaining_requested_token_types_supported`, a parameter defined by the [Identity Chaining](https://startwithidentity.com/glossary/identity-chaining/) draft, and may publish `id_jag_signing_alg_values_supported`. A target authorization server lists `urn:ietf:params:oauth:grant-profile:id-jag` in `authorization_grant_profiles_supported`. Revision -06 also adds sections on DPoP key binding, so an ID-JAG can carry a `cnf` claim and be redeemed only by the holder of that key.

## What it solves for AI agents and SaaS

For SaaS, the problem is consent sprawl. Every "connect app" click creates a long-lived OAuth grant that the identity team cannot see in one place and cannot revoke when someone leaves. With ID-JAG, the IdP sits in the middle of every connection, so admins can allow, deny and log app-to-app access the same way they manage SSO assignments.

For AI agents the effect is larger. An agent that uses ten tools would otherwise ask the user to approve ten consent screens and then keep ten refresh tokens. Under ID-JAG the agent host asks the IdP for a grant per target as needed, gets short-lived tokens, and loses access when the IdP policy or the user's account changes. That is why the [MCP authorization](https://startwithidentity.com/standards/mcp-authorization/) ecosystem adopted it as the Enterprise-Managed Authorization extension.

What it does not solve: agents acting as themselves (use client credentials or [workload identity](https://startwithidentity.com/glossary/workload-identity/)), access between organizations that do not share an IdP, and enforced multi-hop [delegation chains](https://startwithidentity.com/glossary/delegation-chain/). The `act` claim can name the agent, but neither ID-JAG nor RFC 8693 makes prior actors enforceable.

## Adoption signals (verified)

- **Okta Agent SSO.** Okta [announced general availability](https://www.okta.com/newsroom/press-releases/okta-brings-first-class-identity-to-ai-agents-with-agent-sso/) on 24 August 2026, describing it as bringing "the open Cross App Access standard" into Okta SSO at no extra cost, with prebuilt support for apps including Anthropic's Claude, Atlassian, Notion and Slack.
- **MCP Enterprise-Managed Authorization.** A [stable extension](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx) for MCP revision 2026-07-28 that applies ID-JAG to MCP clients and servers.
- **Official MCP TypeScript SDK.** The client package's [auth extensions](https://github.com/modelcontextprotocol/typescript-sdk/blob/main/packages/client/src/client/authExtensions.ts) include a provider that exchanges an ID token for an ID-JAG via RFC 8693, checked on 5 November 2026.

We found no other IdP with documented general availability as of this review. Absence here means "not verified", not "not shipped".

## How to implement or evaluate

- **If you run the IdP:** confirm your vendor supports issuing ID-JAGs through token exchange, and how policy is expressed (per client, per audience, per scope, per group). Ask whether issued grants are logged with the user, client and target, and whether revoking the user's session stops new grants.
- **If you build a SaaS app (the target):** accept the `jwt-bearer` grant with the ID-JAG profile, require client authentication (the draft says the server must reject requests with neither client authentication nor a sender-constrained grant), validate `aud` against your own issuer identifier exactly, enforce single use of `jti`, and issue short-lived access tokens. Keep your own policy: the draft is explicit that the target still decides.
- **If you build an agent or MCP client:** store the user's ID token or refresh token as a high-value secret, request one audience per exchange, pass the `resource` value from the target's [protected resource metadata](https://startwithidentity.com/glossary/protected-resource-metadata/) unchanged, and ask for the narrowest scope.
- **Pin and test.** Record which revision you implement. The MCP extension links -04 while the current text is -06, so check processing rules against the revision your counterparties use.

## Pitfalls

- **The IdP becomes a single point of authorization.** A compromised IdP admin or a broad policy ("any app may reach any app") recreates the sprawl you were trying to remove, centrally. Review policies like privileged access.
- **Subject mapping errors.** The target must map `sub` (or a SAML NameID in `sub_id`) to the same user its SSO already resolves, including tenant. Mismatches can grant access to the wrong account in multi-tenant setups.
- **Stored subject tokens.** Holding ID tokens or refresh tokens in an agent runtime that reads untrusted input is a real exposure, covered in our [agent instruction injection](https://startwithidentity.com/techniques/agent-instruction-injection/) technique brief.

## Related

[MCP authorization](https://startwithidentity.com/standards/mcp-authorization/), [OAuth Transaction Tokens](https://startwithidentity.com/standards/oauth-transaction-tokens/), [OAuth 2.1](https://startwithidentity.com/standards/oauth-2-1/), the [Agent Identity Standards Map 2026](https://startwithidentity.com/reports/agent-identity-standards-map-2026/), the [securing AI agent identities](https://startwithidentity.com/guides/machine-identity/securing-ai-agent-identities/) guide, and our analysis [agent identity just got a protocol](https://startwithidentity.com/blog/agent-identity-gets-a-protocol/). Glossary: [token exchange](https://startwithidentity.com/glossary/token-exchange/), [identity chaining](https://startwithidentity.com/glossary/identity-chaining/), [agentic identity](https://startwithidentity.com/glossary/agentic-identity/), [credential brokering](https://startwithidentity.com/glossary/credential-brokering/).

## Who wrote it

The draft is edited by [Aaron Parecki](https://startwithidentity.com/experts/aaron-parecki/), Karl McGuinness and [Brian Campbell](https://startwithidentity.com/experts/brian-campbell/). More in the [experts directory](https://startwithidentity.com/experts/).