ID-JAG lets one application obtain an access token for another application’s API by coordinating through an identity provider both applications already trust. It brings enterprise policy to app-to-app delegation without forcing the user through a fresh consent redirect at every resource.

That makes ID-JAG important for MCP and agentic software. It does not make it an agent-identity standard.

ID-JAG answers whether an application may call an API for a user under identity-provider policy. It does not describe an autonomous agent, task limits, delegation depth, or tool arguments.

Cross App Access starts with shared SSO trust

Enterprise applications already trust the same identity provider for sign-in. An employee signs into a client application with OpenID Connect or SAML and receives an identity assertion. A resource application trusts the same provider to establish workforce identity and policy.

Cross App Access, or XAA, uses that existing trust to broker API access.

The IETF mechanism is the Identity Assertion JWT Authorization Grant, shortened to ID-JAG. Revision -04, published 21 May 2026, is an adopted OAuth Working Group document. It remains an Internet-Draft.

The flow has two exchanges:

Employee   Client app     Enterprise IdP     Resource AS      API
   │           │                │                 │            │
   │─ sign in >│                │                 │            │
   │           │─ exchange ────>│                 │            │
   │           │<── ID-JAG ─────│                 │            │
   │           │──── JWT bearer grant ───────────>│            │
   │           │<──── resource access token ──────│            │
   │           │──────────────── API request ─────────────────>│

The enterprise IdP issues the grant. The resource authorization server still issues the token accepted by its API.

The first exchange creates a short-lived grant

The client begins with an identity assertion, normally an OIDC ID token or SAML assertion. It presents that assertion to the enterprise identity provider using RFC 8693 Token Exchange and asks for:

urn:ietf:params:oauth:token-type:id-jag

The identity provider evaluates which user signed in, which client is asking, which resource authorization server is targeted, and which permissions are requested. If allowed, it returns a short-lived signed ID-JAG. The draft’s examples use a 300-second lifetime.

{
  "typ": "oauth-id-jag+jwt",
  "iss": "https://idp.example.com/",
  "sub": "employee-1842",
  "aud": "https://resource.example.com/",
  "client_id": "client-app-27",
  "exp": 1786531500,
  "scope": "documents.read"
}

This is not the API access token. Its audience is the resource authorization server.

The second exchange preserves resource control

The client presents the ID-JAG to the resource authorization server with the JWT bearer grant defined by RFC 7523. The resource server’s authorization service validates the grant, maps the subject to its local account or tenant, applies policy, and issues its own access token.

The resource remains in control of:

which identity providers it trusts;
whether the client registration is valid;
how the subject maps into its tenant;
which permissions survive; and
which access token reaches its API.

ID-JAG carries identity and delegated policy across a trust boundary. It does not replace the resource’s authorization server.

A normal authorization-code flow redirects the user to each resource’s authorization server. That becomes friction when an enterprise has already decided which managed applications may access which company services.

ID-JAG lets the enterprise identity provider make the cross-app policy decision. A user signs in once; managed applications obtain API access according to centrally administered rules.

MCP’s Enterprise-Managed Authorization extension applies this pattern to managed MCP clients and servers. It became stable on 18 June 2026.

“Zero-touch” does not mean “uncontrolled.” It means identity-provider policy replaces repeated end-user consent.

ID-JAG also fits customer identity

The draft’s trust model applies beyond workforce IAM. A CIAM platform can issue an identity assertion for a customer, and a third-party resource authorization server can map that customer into a local account before issuing an API token.

This matters when shopping assistants, financial dashboards, or developer tools need access at another service without sending the customer through a new login ceremony each time. ID-JAG provides the bridge when the parties establish the required trust.

It is not open-ended federation. The parties must agree on issuers, audiences, clients, tenants, subject mapping, and policy. Public metadata must avoid exposing sensitive trust topology.

ID-JAG does not identify the agent

An application can use ID-JAG while an AI agent drives its behavior. The grant still identifies the user and client application. It does not standardize:

a named agent principal;
the model or runtime executing the task;
a human owner or sponsor;
task-scoped tool and argument constraints;
recursive delegation to sub-agents; or
the intent behind an API call.

That is outside ID-JAG’s scope. The mistake is marketing app-to-app delegation as if it solved agent authority.

An enterprise can correctly approve client-app-27 to read documents for employee-1842 while still having no idea which internal agent selected a document, why it selected it, or whether injected content changed the plan. OAuth solved agent access, not agent authority covers the missing layer.

Tenant mapping is the hard deployment work

The protocol diagram is cleaner than the deployment. A single issuer can serve several tenants. The same sub value is not necessarily globally unique without issuer and tenant context. A resource may already have a local user created through just-in-time provisioning.

Implementers should test:

issuer plus tenant plus subject uniqueness;
a grant presented to the wrong resource tenant;
client ID mapping across authorization servers;
stale authentication assurance and step-up;
revoked enterprise access after assertion issuance; and
sender-constrained grant requirements where configured.

This belongs in an identity platform rather than an application-side token script. The happy path is two token calls. The security boundary is the trust graph behind them.

The maturity map matters

Component	Status in August 2026
RFC 8693 token exchange	Standards Track RFC
RFC 7523 JWT bearer grant	Standards Track RFC
ID-JAG	Adopted OAuth WG Internet-Draft `-04`
MCP Enterprise-Managed Authorization	Stable MCP extension
Agent identity and task authority	Outside ID-JAG

You can build against the current draft in a managed deployment with explicit version negotiation. Do not describe it as a finished RFC or assume every enterprise IdP can issue it.

ID-JAG’s contribution is precise: it turns shared sign-in trust into a short-lived cross-app authorization grant while leaving resource access tokens under resource control. It is valuable partly because it does not pretend to solve the rest of agent identity.

ID-JAG and Cross App Access: Enterprise Delegation Explained