Validate ID-JAGs for your MCP server
If you build an MCP server and sell it to enterprises (the B2B MCP case), you can turn on ID-JAG validation as a value-add for every customer.
Each customer lets their users and agents reach your MCP server from the identity provider they already run: Okta's for AI agents, Microsoft Entra, or their own Descope Agentic Identity Hub if they run their employees and agents on Descope too.
Descope, acting as the authorization server for the MCP server you built with Descope MCP Auth, accepts the ID-JAGs each customer's IdP issues, validates them against that customer's trusted issuer, and mints an ordinary Descope access token for your server. Your MCP server does not need to understand ID-JAG at all.
You do not provision the customer's users; their admin controls access in their own IdP, and your MCP server honors what it decides.
Note
For the grant itself and how this compares to issuing ID-JAGs for your own agents, see the Enterprise-Managed Authorization overview.
How it Works
However the agent obtained its ID-JAG, the part you configure is the same. The agent presents that ID-JAG to your Descope-protected MCP server, Descope matches the assertion's subject to the user provisioned from that customer's SSO in the matching tenant, and it mints an access token for your server.
This works the same whether the ID-JAG came from Okta or any other workforce IdP the customer uses, that supports ID-JAG.
Descope accepts the ID-JAG from any IdP you trust on the tenant, matches its subject to the SSO user in that tenant, and mints an access token. It returns that token to the agent, which then calls your MCP server (the Resource) with it. Your server validates that token like any other request.
Your MCP server is the Resource
The target being protected is your own MCP server, registered in Descope as an MCP Server Resource. Its URL is the audience the customer's IdP names when it mints an ID-JAG, and it is what Descope issues the final access token for. Your server validates that token exactly as it does for any other request.
Enable Trusted Issuers per Tenant
Each enterprise customer is a tenant in your Descope project. Under a tenant, you register that customer's workforce IdP as a trusted issuer whose ID-JAGs Descope will accept for your MCP server.
This reuses the JWT Bearer grant: you add the issuer's URL and JWKs, and Descope accepts assertions signed by it.
Because trust is scoped to the tenant, each customer's users flow through their own IdP, and an ID-JAG minted for one customer can never buy access for another.
Note
The customer's workforce IdP owns the first authorization decision: whether a given client may request cross-app access to your MCP server at all, through its own Cross App Access configuration. Descope owns the second: which scopes the resulting Descope token carries. See Agent Authorization for how those scopes are resolved.
Setup Instructions
Protect your MCP server
Create the MCP Server Resource and stand up Descope MCP Auth as you would for any MCP server you operate.
Add a tenant per customer
Represent each enterprise customer as a tenant.
Register the customer's workforce IdP as a trusted issuer
On that tenant, enable the JWT Bearer grant and add the customer IdP's Issuer URL and JWKs URL so Descope accepts its ID-JAGs.
Write policies
Use policies to decide which scopes the exchanged token carries, keyed on user.roles, user.tenantIds, and claims carried over from the assertion.
VS Code
Configure VS Code to authenticate to your Descope project once, then connect to enterprise-managed MCP servers silently.
Agent Authorization
How policies govern agent access to Resources and Connections, with recommended patterns for MCP servers, backend APIs, and third-party credential brokering.