Identity Assertion JWT Authorization Grant
Identity Assertion JWT Authorization Grant (ID-JAG).
ID-JAG is a short-lived JWT, minted by a company's enterprise identity provider, that lets one app get an access token for another app's API on behalf of a signed-in user, but only if the IdP's admin policy allows it.
The point of ID-JAG is to move the consent decision from the end user to the company's identity admin. Without it, an AI agent or SaaS app connects to another app through a per-user OAuth consent screen, and IT has no central record of which app reached which. With ID-JAG, the identity provider becomes the policy enforcement point. It mints the assertion only when the admin's policy allows that requesting app to reach that resource app for that user.
ID-JAG reuses two existing standards rather than inventing a new protocol. The first hop is OAuth 2.0 Token Exchange (RFC 8693). The second hop is the JWT Profile for OAuth 2.0 Authorization Grants (RFC 7523). Per WorkOS's analysis, the client_id inside an ID-JAG is a Client ID Metadata Document identifier, which is how the IdP knows which piece of software is asking.
For B2B SaaS teams, the practical work sits on the resource side. Your authorization server has to accept jwt-bearer grants from your customers' IdPs and map the ID-JAG's subject to an account in the right tenant. The enterprise-managed authorization guide covers that build. The vendor-side name you will hear most is Cross App Access.
Common questions
What does ID-JAG stand for?
ID-JAG stands for Identity Assertion JWT Authorization Grant. It is an IETF OAuth Working Group draft, currently draft-ietf-oauth-identity-assertion-authz-grant-04 (21 May 2026), authored by Aaron Parecki, Karl McGuinness, and Brian Campbell.
How does an ID-JAG flow work?
The requesting app exchanges the user's ID token or SAML assertion at the enterprise IdP using RFC 8693 Token Exchange. If admin policy allows, the IdP returns an ID-JAG for the target audience. The app then presents the ID-JAG to the resource app's authorization server as an RFC 7523 JWT bearer grant and receives an access token.
What does a resource app need to accept ID-JAG?
Its authorization server must accept the RFC 7523 jwt-bearer grant, advertise urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported in its RFC 8414 metadata, and trust the enterprise IdP that issued the ID-JAG. It validates the oauth-id-jag+jwt typ header, issuer, audience, and expiry before issuing its own access token.
Is ID-JAG the same as Cross App Access?
Cross App Access (XAA) is Okta's product name for the ID-JAG pattern. The Model Context Protocol calls the same idea the Enterprise-Managed Authorization extension. ID-JAG is the underlying IETF draft and token format.
Related terms
In the guides
Authentication for AI Agents: OAuth Patterns for Non-Human Identity
How AI agents authenticate in 2026. The on-behalf-of pattern, delegated agent identity, OAuth 2.1 Dynamic Client Registration, and where the patterns are still being invented.
Enterprise-Managed Authorization: Cross App Access, ID-JAG, and CIMD for B2B SaaS
How enterprise customers let AI agents reach your SaaS API or MCP server under their IdP policy. ID-JAG, CIMD, and Cross App Access explained for B2B builders.
MCP Server Identity Model: Authentication, Authorization, and Trust for the Model Context Protocol
MCP is OAuth 2.1 with discovery. How MCP clients identify themselves (CIMD first, DCR as fallback), how servers scope access, and what the spec leaves to you.