What is MCP's Enterprise-Managed Authorization extension (ID-JAG, also called Cross App Access or XAA)? How does it work, what does my MCP server or its authorization server have to do to support it, and should I?

What should I check, step by step?

1. Decide whether your customers need it. The extension is written for MCP clients and servers that both sit behind an enterprise IdP. If most of your users sign in as individuals, the standard MCP OAuth flow stays your main path; the extension doesn't replace it.

2. Check whether your authorization server already accepts ID-JAGs before building anything. The MCP extension page lists products with documented support, including Okta, Ping Identity (PingFederate 13.1 and later), Descope, Stytch, Athenz, ThunderID and AuthPlane, with Auth0, WorkOS AuthKit and Scalekit in early access and Keycloak experimental. It also names Cloudflare's workers-oauth-provider (experimental, 0.7.0 and later) and FastMCP 4.0 and later (beta).
3. Accept the grant type urn:ietf:params:oauth:grant-type:jwt-bearer at your token endpoint, with the ID-JAG as the assertion, and authenticate the client with the credentials it registered with you. The extension says a client that isn't pre-registered can use its Client ID Metadata Document URL as its client_id.
4. Validate every ID-JAG: the JWT's typ is oauth-id-jag+jwt, the signature verifies against the keys of an IdP you trust for that customer, iss is that IdP, aud is your authorization server's issuer identifier, exp hasn't passed, and client_id matches the client presenting it. If a resource claim is present it must be your MCP server's resource identifier.
5. Issue access tokens audience-restricted to the MCP server named in the ID-JAG's resource claim; the extension makes that a MUST. Your MCP server still validates the audience of every token it receives.
6. Trust IdPs per customer, not globally. An ID-JAG is only as trustworthy as the issuer you accept it from, and the IETF draft has a section on multi-tenant issuers and subject identifier uniqueness. Configure which issuer belongs to which customer organisation.
7. Use the sub claim as the stable identifier for the user. The MCP extension page says email may also be present and suggests using it only to link pre-existing accounts created before enterprise-managed authorization was turned on.
8. Map the ID-JAG's scope to your own permissions and refuse scopes the customer's policy didn't grant. Define scopes fine enough that an IdP admin can, for example, give one group read-only access and another read-write.
9. Advertise support: add urn:ietf:params:oauth:grant-profile:id-jag to authorization_grant_profiles_supported in your authorization server metadata, which is how the extension says clients discover it.
10. Keep a record of grants outside the token flow. The extension says the IdP sees only token issuance, not the MCP traffic itself, so log which client used which scopes on which server for whom, and keep offboarding at the IdP as the off switch.

How does MCP enterprise-managed authorization (ID-JAG) work step by step?

The extension, at protocol revision 2026-07-28, is an application of the IETF OAuth working group draft Identity Assertion JWT Authorization Grant, which is itself a profile of the Identity Chaining Across Trust Domains draft. It has three steps: single sign-on to the MCP client with OpenID Connect or SAML; a Token Exchange request (RFC 8693) to the IdP that names the MCP server's authorization server as the audience and returns an ID-JAG; and a JWT authorization grant (RFC 7523) at that authorization server, which returns an access token.

• In the Token Exchange request, requested_token_type is urn:ietf:params:oauth:token-type:id-jag, audience MUST be the issuer identifier of the MCP server's authorization server, and resource is optional but, if set, MUST be the MCP server's resource identifier as defined in RFC 9728. The IdP evaluates the policies its administrators set and decides whether this client may act for this user on this server with these scopes. The extension's example response has an expires_in of 300 seconds.
• The ID-JAG is a JWT signed by the IdP with claims including jti, iss, sub, aud, resource, client_id, exp, iat and scope, and optionally email. It isn't an access token for your API: the client must exchange it at your authorization server, and the extension tells clients not to redirect the user to your authorization endpoint at all.

Does MCP enterprise-managed authorization let a company's IdP see or approve individual MCP tool calls?

The MCP extension page lists the benefits: employees use corporate SSO with no per-server consent prompts, the IdP keeps one place to decide which MCP servers are approved and for whom (group membership, roles, conditional access), and revoking an employee's access happens at the IdP for every MCP client at once instead of server by server. That stops new ID-JAGs; access tokens your authorization server has already issued are a separate matter, so keep them short-lived or revocable (the extension's example access token has an expires_in of 86,400 seconds, one day).

• The extension's own security section sets the limit: the IdP's visibility is limited to issuing the access token and doesn't extend to the MCP traffic between client and server. The IdP can control which users may use which clients with which servers, and which scopes they may request if your scopes are fine-grained, but it doesn't see or approve individual tool calls.
• It also expects the MCP client to be pre-registered with the IdP for single sign-on in most enterprise deployments. Enterprise-managed authorization is an addition for SSO customers, not a way around client registration.

Is the ID-JAG / Cross App Access standard for MCP final, and which clients and identity providers support it?

The extension page says support varies by client and that extensions are opt-in and never active by default; it points to the MCP client matrix for current status. A server that requires the enterprise flow will turn away clients that haven't implemented it, so keep the standard MCP authorization flow available unless every customer's client supports it.

• The underlying draft isn't an RFC. The IETF Datatracker lists draft-ietf-oauth-identity-assertion-authz-grant as an active OAuth working group document; revision -06 was posted at the end of October 2026, while the MCP extension text links to revision -04. The extension page notes that implementations track different draft revisions, for example the Keycloak guide targets revision 01 and the Janssen Project targets revision 04, so check which revision each IdP and authorization server you depend on implements.
• Vendor terms differ too. Okta calls this Cross App Access, and the MCP extension page says issuing is included in Okta SSO for Identity Engine orgs, capped at 250 ID-JAGs per user per resource app per month, with higher volume requiring Okta for AI Agents. Plan for a client asking for a fresh ID-JAG each time its access token expires.