Issue ID-JAGs for your agents

Make Descope the identity provider for the AI agents you run so they can reach third-party MCP servers and backend APIs whose authorization server supports ID-JAG. Your agent authenticates with Descope, exchanges its token for an ID-JAG scoped to the target, and the downstream server validates it against Descope's public keys and issues its own access token. The user never sees a second consent screen.

What each agent is allowed to reach is decided by policies, and you see and revoke every agent in the Agentic Identity view. This page is about the issuing side, which means registering the target as a Resource and minting the ID-JAG.

Because Descope mints the ID-JAG, it enforces those policies in the request path without you building a gateway or an intermediate MCP server between your agent and the downstream resource. That only works when the downstream accepts ID-JAGs; when it does not, building that intermediary with a Connection is the alternative.

For the grant itself and how this compares to validating ID-JAGs for your own MCP server, see the Enterprise-Managed Authorization overview.

Why ID-JAG?

Enterprise-managed authorization moves who can access what from each MCP server's own admin console into Descope, where you set policies once and Descope acts as the issuer.

The diagrams below use the same five MCP servers. You can compare per-server authorization and consent screens with a single central IdP, using Enterprise-Managed Authorization.

Without Enterprise-Managed Authorization

Without enterprise-managed auth

Each MCP server manages its own authorization

Starting…5 consent prompts · per-server auth

Without enterprise-managed authorization, each MCP server runs its own OAuth flow and manages access in its own admin console. The user signs in and approves scopes on every server — Linear, then Canva, then GitHub, and so on. There is no central place to see who has access, set policy once, or revoke an agent across every service.

With ID-JAG (Enterprise-Managed Authorization)

Enterprise-managed access

One sign-in — authorization governed centrally by Descope

Connecting…0 consent prompts · central policies

The user signs in once to Descope, your enterprise IdP and ID-JAG issuer. Descope mints a separate assertion for each MCP server the agent is entitled to and connects them all in a single burst. Access is governed centrally through policies you set on each Resource — one place to allow, audit, and revoke agent access across every downstream service.

How it works

Two things have to be true before an agent can reach a third-party server. The target has to be a Resource in Descope, and a policy has to allow the agent to request an ID-JAG for it.

An ID-JAG grants access to a Resource, and its aud claim is that Resource's identifier, so you register the third-party MCP server as a Resource whose URL matches the server you actually connect to. This is a Resource, not a Connection. You are not vaulting a token to replay later; you are minting a signed assertion that the downstream authorization server honors on its own.

Which Resources an agent may reach, and with which scopes, is decided by policies. Those decisions are grounded in the real users in your tenant. The ID-JAG asserts a user identity from your organization, and the policy evaluates that user's roles and permissions, so an agent never gets broader access than the user it acts for.

Setup Instructions

Create an MCP Server Resource

In the Descope Console, create a Resource of type MCP Server. Set the MCP Server URL to the exact URL of the third-party MCP server you want to reach. That URL becomes the aud of the ID-JAG, which is how the downstream authorization server recognizes the assertion as meant for it.

For example, if Canva's MCP server is https://mcp.canva.com/mcp, set the Resource's MCP Server URL to https://mcp.canva.com/mcp.

Note

The URL must match the downstream server exactly. A trailing-slash or path mismatch produces an audience the downstream server will reject.

Add the same scopes as the downstream server

Define scopes on the Resource that are identical to the scopes the downstream MCP server expects. The ID-JAG, and the access token the downstream server mints from it, carries these scopes, so they must match what that server publishes.

Check the third-party server's documentation or its OAuth metadata for the scope names, and mirror them on your Resource.

Set Descope as the client's IdP (and pre-register it if needed)

In your MCP client's Enterprise-Managed Authorization (Cross App Access) settings, set the identity provider to Descope, using your project issuer.

The issuer is <base-url>/v1/apps/<your-project-id>, where <base-url> is your region's Descope base URL (for example https://api.descope.com), or your custom domain if you have one set up for your Descope project. The ID-JAG carries the same issuer as your Descope access tokens.

Whether you also pre-register a client depends on the MCP client:

Clients that support CIMD (for example Claude Code or VS Code) register with Descope automatically; there is nothing to create.
Clients that do not support CIMD must be pre-registered: create the client in Descope and hand its ID and secret to the MCP client.

See the setup guides for the exact per-client steps.

Write a token-exchange policy

Create a policy that governs who can obtain an ID-JAG for this Resource. Set the grant type to Delegated access (token exchange), then define:

Subject: which agents or users the rule applies to (for example a client tag like verified-agent, or a user role).
Target: the MCP Server Resource you created, and the allowed scopes on it.

Only subjects a policy allows can exchange their Descope token for an ID-JAG on that Resource, and only for the scopes the policy permits. Because the subject resolves to a real user in your tenant, an agent never gets broader access than that user has.

Exchange the token at runtime

The agent calls the token endpoint (RFC 8693) to exchange its Descope token for an ID-JAG scoped to the Resource, then presents that ID-JAG to the downstream server's authorization server to receive an access token. Clients like Claude Code and VS Code do this for you automatically.

Specific Setup Guides

Point popular MCP clients at your Descope project as their Enterprise-Managed Authorization identity provider. Once configured, the client signs in to Descope once and reaches every enterprise-managed MCP server without another prompt.

Claude Code

Enable XAA, connect to Descope, and add MCP servers from the CLI. Uses CIMD when you omit client credentials.

VS Code

Set the Descope identity provider in settings.json and list each MCP server in mcp.json with enterprise-managed auth.

Was this helpful?

Claude Code

VS Code

On this page