Enterprise-Managed Authorization (ID-JAG)

Enterprise-Managed Authorization lets an agent signed in to one application reach another application's API or MCP server through the enterprise IdP both apps already trust, with no second login or consent screen.

The name comes from the MCP specification; you may also see it called Cross App Access (XAA).

The mechanism is the Identity Assertion JWT Authorization Grant (ID-JAG), defined in an IETF draft: a short-lived, signed JWT in which the IdP vouches for a specific user, in a specific app, requesting access to a specific resource app. It is minted with OAuth token exchange (RFC 8693) and redeemed with the JWT Bearer grant (RFC 7523). The resource app's authorization server still issues its own access tokens; the IdP only brokers the trust.

Two use cases

Descope sits on either side of an ID-JAG exchange. Pick the one that matches you: issuing ID-JAGs for the agents you run, or validating the ID-JAGs that reach an MCP server you sell.

Issuing ID-JAGs — You run the agents. Descope is their identity provider: when an agent needs to reach a third-party MCP server or API, Descope mints the ID-JAG. You register those downstream services as Resources and govern access with policies.

Validating ID-JAGs — You sell the MCP server. Each enterprise customer connects their workforce IdP (Okta, Entra, or another Descope project). Descope validates the customer's ID-JAG and issues your server a normal access token, so customers control who reaches your product without a second login.

ID-JAG or a Connection?

For the issuing use case, "my agents need to reach an external service," there are two ways to enforce policy between your agent and that service. Which one you use depends on whether the downstream supports ID-JAG. (This choice does not apply to the validator use case, which is only about protecting your own MCP server for customers.)

• Downstream supports ID-JAG: be the issuer. Descope mints a scoped ID-JAG per request, so it enforces your policies and sits in the path of every request with nothing to build in between. The downstream authorization server validates the assertion and issues its own token; no credential is stored.
• Downstream does not support ID-JAG: use a Connection. Descope stores the downstream's OAuth token or API key (each user consents once, or a tenant admin stores a tenant-level token) and returns it, refreshed, when a tool runs. To keep policy between your agent and the service, you put a Resource in between (a gateway or MCP server you build) that holds the Connection and does the exchange.

The advantage of being the ID-JAG issuer is that Descope enforces policy in the request path without a gateway or an intermediate MCP server. When the downstream cannot accept an ID-JAG, that intermediary is the alternative.