Who’s on FirstChoose a flow

Flows / Delegation chains

Enterprise-managed authorization (ID-JAG)

The company identity provider decides which agents may reach which apps for which employees. No per-app consent screens.

Based ondraft-ietf-oauth-identity-assertion-authz-grantWG draft, revision -06Guide reviewedNovember 2026

Sources and review details
This page
Implementation guideAn explanation, not a specification
Primary specification
Identity Assertion Authorization Grant (ID-JAG)WG draft · Revision -06, October 2026
All 6 specifications
3 published, 3 drafts
Flow maturity
EmergingWhat the rating means
Human involvement
Human present
Review
Checked against sources in November 2026How it was checked

Inside a company, per-user consent is the wrong control. An employee clicking “Allow” twenty times does not give the security team visibility into which AI tools are connected to which systems, and the employee is not the one who should be deciding.

The Identity Assertion JWT Authorization Grant, or ID-JAG, moves the decision to the identity provider the company already uses for single sign-on. The agent signs the user in once. When it needs access to another application, it asks the identity provider for a short-lived assertion aimed at that application’s authorization server. The identity provider applies administrator policy and either issues it or refuses. The agent trades the assertion for an ordinary access token.

No browser redirect, no consent prompt, and one place where access is granted, logged and revoked. Vendors market this as Cross App Access. In MCP it is the official Enterprise-Managed Authorization extension.

Step by step

9 steps between 4 parties. Each step shows the message and who holds which credential afterward. Use ←→ or select any arrow.

Sequence diagram4 participants, 9 steps
  • Direct call
  • Via the user’s browser or device
  • Response
  • Local action

Drag to see every party and step. Tap a step to jump to its explanation.

1Singlesign-on (OIDC)2Token exchange:request ID-JAG3Admin policy check4ID-JAG (5 minutes)5JWT bearer grant with ID-JAG6Verify IdP signature and audience7Access token for the MCP server8MCP request + Bearer token9Result

  1. 1AgentEnterprise IdPVia the user’s browser or device

    The user signs in to the agent through the company IdP

    An ordinary OpenID Connect login, the same one used for every other workplace application. The agent receives an ID token asserting who the user is.

    Who holds what after this step

    Agent
    newID token

    Parties not listed hold none of this flow’s credentials at this point.

  2. 2AgentEnterprise IdPDirect call

    The agent asks the IdP for an assertion aimed at the app

    A token exchange (RFC 8693) at the identity provider. The ID token is the subject. audience is the issuer of the application’s authorization server; resource is the MCP server itself.

    POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://auth.chat.example/
&resource=https://mcp.chat.example/
&scope=chat.read chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ…
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id=2ec954a1d60620116d36d9ceb7
&client_secret=…

    Who holds what after this step

    Agent
    ID token

    Parties not listed hold none of this flow’s credentials at this point.

  3. 3Enterprise IdPLocal action

    The IdP applies the administrator’s policy

    Is this client allowed to reach that application, for this user, with these scopes? The answer was configured by an administrator. The user is not asked.

    Who holds what after this step

    Agent
    ID token

    Parties not listed hold none of this flow’s credentials at this point.

  4. 4Enterprise IdPAgentResponse

    The IdP issues the grant

    A signed JWT with its own type, so it cannot be mistaken for an ID token or an access token. It is not usable at the MCP server. Its only purpose is to be presented to the application’s authorization server.

    // header: { "typ": "oauth-id-jag+jwt" }
{
  "jti": "9e43f81b64a33f20116179",
  "iss": "https://acme.idp.example",
  "sub": "U019488227",
  "aud": "https://auth.chat.example/",
  "resource": "https://mcp.chat.example/",
  "client_id": "f53f191f9311af35",
  "scope": "chat.read chat.history",
  "exp": 1311281970,
  "iat": 1311280970
}

    Who holds what after this step

    Agent
    ID tokennewID-JAG (aud: resource AS)

    Parties not listed hold none of this flow’s credentials at this point.

  5. 5AgentResource ASDirect call

    The agent presents the grant to the app’s authorization server

    A standard JWT bearer grant (RFC 7523). The agent authenticates as a client of this authorization server, either pre-registered or by using a Client ID Metadata Document URL as its client ID.

    POST /oauth2/token HTTP/1.1
Host: auth.chat.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJIUzI1NiIsI…
&client_id=https://client.example.com/client.json

    Who holds what after this step

    Agent
    ID tokenused upID-JAG (aud: resource AS)

    Parties not listed hold none of this flow’s credentials at this point.

  6. 6Resource ASLocal action

    The app’s authorization server validates the grant

    It trusts the enterprise IdP because the company’s tenant was configured for single sign-on with it. It checks the signature, that it is the intended audience, that the client matches, and that the grant has not expired or been used.

    Who holds what after this step

    Agent
    ID token

    Parties not listed hold none of this flow’s credentials at this point.

  7. 7Resource ASAgentResponse

    An ordinary access token comes back

    Audience-restricted to the MCP server named in the grant’s resource claim. From here the agent uses it like any other MCP access token.

    Who holds what after this step

    Agent
    ID tokennewaccess token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  8. 8AgentMCP serverDirect call

    The agent calls the application

    The MCP server validates the token exactly as it would one obtained through an interactive flow. It does not need to know the difference.

    Who holds what after this step

    Agent
    ID tokenaccess token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

  9. 9MCP serverAgentResponse

    The application responds

    When the employee leaves, or the administrator withdraws the agent’s access to this application, the identity provider stops issuing grants. Nothing has to be revoked application by application.

    Who holds what after this step

    Agent
    ID tokenaccess token (aud: MCP server)

    Parties not listed hold none of this flow’s credentials at this point.

Watch out for

  • It only works when both sides are connected to the same identity provider. It is not a mechanism for consumer or cross-organization access.
  • The identity provider sees and controls token issuance. It does not see what the agent then does with the token.
  • The underlying IETF specification is still a working group draft, and the MCP extension pins a specific revision. Expect changes.
  • Support is uneven on both ends: the identity provider must issue ID-JAGs and each application’s authorization server must accept them.

How this differs from token exchange

In plain token exchange one authorization server issues both tokens. Here there are two: the identity provider issues a grant, and a different authorization server turns it into an access token. That split is what lets it cross between applications from different vendors. ID-JAG is a profile of the more general identity chaining pattern.

Standards in play

See the full tracker for status and links.

Final specio.modelcontextprotocol/enterprise-managed-authorization

MCP Enterprise-Managed Authorization

Central, administrator-controlled access for workforce agents, with no per-server consent prompts.

RFCRFC 8693

Token Exchange

The primitive under on-behalf-of flows, ID-JAG, identity chaining and transaction tokens.

WG draftdraft-ietf-oauth-client-id-metadata-document

Client ID Metadata Documents

The preferred way for an MCP client to identify itself to a server it has never met.

MCP authorization

How an MCP client that has never seen a server before discovers where to sign in, identifies itself, and gets a token good for that server alone.

Human presentEmerging

Token exchange

Trade the token you were given for a new one that names both the user and the service now acting for them.

With or without a humanStable standards

Identity chaining

Carry who-is-this-for across an organizational boundary, with each side keeping control of its own tokens.

With or without a humanEmerging

Authorization code + PKCE

The baseline. A person signs in, approves specific scopes, and the agent receives a token that says so.

Human presentStable standards