# 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?

**Short answer:** It's an optional MCP extension, io.modelcontextprotocol/enterprise-managed-authorization, that lets a company's identity provider (IdP) decide which employees may use which MCP clients with which MCP servers, instead of each employee clicking through an OAuth consent screen for every server. The employee signs in to the MCP client with company SSO. The client then trades that sign-in (an OpenID Connect ID token, or a refresh token obtained from a SAML assertion) at the IdP for a short-lived signed grant called an Identity Assertion JWT Authorization Grant (ID-JAG), using OAuth Token Exchange (RFC 8693). The IdP checks its admin policy before issuing it. The client presents the ID-JAG to your MCP server's authorization server as a JWT bearer grant (RFC 7523), and your authorization server validates it and issues an ordinary access token that must be audience-restricted to your MCP server. Okta markets this as Cross App Access (XAA); the MCP spec doesn't use that term. To support it, your authorization server has to accept the jwt-bearer grant, validate ID-JAGs from each customer's IdP (signature, issuer, audience, expiry, client and resource), map the subject to an account, and advertise urn:ietf:params:oauth:grant-profile:id-jag in its metadata. It's worth doing if you sell to companies that run workforce SSO, and premature if your users are mostly individuals. The underlying IETF draft isn't an RFC yet, client support varies, and extensions are opt-in and never on by default.

## Checklist
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.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "Our IdP now lets the engineering group use our coding agent with the source-control MCP server, read-only, until the end of the quarter. Record that grant so we can show who authorized it and whether it was in force on any given day."

```json
{
  "tool": "record_access_grant",
  "arguments": {
    "workspace_id": "<your operations workspace id>",
    "agent_label": "Coding agent (engineering group, via IdP policy)",
    "resource": "Source-control MCP server",
    "grantor": "Identity and access admin",
    "scope": "Read-only scopes as granted by the IdP policy; no write or admin tools.",
    "expires_at": "2026-12-31T23:59:59Z"
  }
}
```
- Needs your account key. It's in the operations toolset (connect to /mcp?toolset=operations) with revoke_access_grant, check_access_grant and verify_access_record.
- It records the grant; it doesn't issue or validate ID-JAGs or tokens. Enforcement stays with your IdP, your authorization server and your MCP server. check_access_grant answers in force, not yet valid, expired or revoked for any moment, and revoke_access_grant records the end when the IdP policy changes.
- Before an IdP admin approves a server, precall_check reads what's on record about it: registry entry, a live probe of its tool definitions against the recorded fingerprint, an invisible-text scan and any security flags. It's evidence to decide from, never a finding that a server is safe.

_Rightshold records access grants and reports what it has on record. It isn't an identity provider or an OAuth authorization server, doesn't issue or validate ID-JAGs, and isn't affiliated with the MCP project, the IETF or any vendor named here. Requirements are quoted from the MCP Enterprise-Managed Authorization extension (revision 2026-07-28) and the IETF draft as checked on November 10, 2026._

## Sources
- [MCP Extensions: Enterprise-Managed Authorization (overview, implementation guide, implementation support table)](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization)
- [MCP ext-auth: Enterprise-Managed Authorization specification, revision 2026-07-28](https://github.com/modelcontextprotocol/ext-auth/blob/main/specification/stable/enterprise-managed-authorization/2026-07-28/enterprise-managed-authorization.mdx)
- [MCP: SEP-990, Enable enterprise IdP policy controls during MCP OAuth flows](https://modelcontextprotocol.io/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o)
- [MCP Extensions: Client support matrix](https://modelcontextprotocol.io/extensions/client-matrix)
- [IETF Datatracker: Identity Assertion JWT Authorization Grant (draft-ietf-oauth-identity-assertion-authz-grant)](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)
- [RFC 8693: OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693)
- [RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants](https://www.rfc-editor.org/rfc/rfc7523)
- [RFC 9728: OAuth 2.0 Protected Resource Metadata](https://www.rfc-editor.org/rfc/rfc9728)
- [Okta Developer: Cross App Access (XAA)](https://developer.okta.com/docs/concepts/xaa/)
- [Auth0 Docs: Cross App Access (XAA)](https://auth0.com/docs/ai-agents-mcp/cross-app-access)

## Related
- [Should an MCP server still support Dynamic Client Registration, or switch to Client ID Metadata Documents?](https://www.rightshold.com/answers/should-an-mcp-server-still-support-dynamic-client-registration-or-switch-to-client-id-metadata-documents)
- [How to do OAuth token exchange so an MCP server never forwards user tokens](https://www.rightshold.com/answers/how-to-do-oauth-token-exchange-so-an-mcp-server-never-forwards-user-tokens)
- [MCP OAuth wrong-audience tokens: what they are and how to defend](https://www.rightshold.com/answers/mcp-oauth-wrong-audience-tokens)
- [How to inventory MCP servers with scope, owner and revocation](https://www.rightshold.com/answers/how-to-inventory-mcp-servers-with-scope-owner-and-revocation)

_Not legal advice. Updated 2026-11-10. JSON: https://www.rightshold.com/answers/what-is-mcp-enterprise-managed-authorization-id-jag-and-should-your-mcp-server-support-it.json_