Let Customers Manage Their Agents

Use this guide when you host an MCP server for your customers (the B2B MCP case) and each enterprise customer should govern their own users and agents with their XAA-compatible workforce IdP.

Customers keep using Okta, Ping, or their own Descope project, as their XAA-enabled workforce IdP. Their IT decides which agents may reach your server. Descope, as the authorization server for the MCP server you protect with Descope MCP Auth, accepts that customer's XAA token (ID-JAG), validates it against the issuer you trusted for that tenant, and mints an ordinary Descope access token for your server. Your MCP server does not need to understand ID-JAG.

You do not provision the customer's workforce users for this path; their admin controls access in their IdP, and your MCP server honors what it decides. For the protocol, see How XAA and ID-JAG work.

How It Works

The premise is that two organizations each decide the half of the question they actually own. The customer's IdP decides whether one of their agents may reach your MCP server at all, because only they know their own employees and their own policies. Descope, sitting in front of that server, decides what that agent gets once it arrives, because only you know your server's scopes.

Cross App Access is the handoff between those two decisions. The customer's IdP writes its decision into a short-lived signed assertion, the ID-JAG, and Descope verifies that assertion before honoring it.

However the customer's agent obtained its XAA token, the part you configure is the same. The agent presents that token to your Descope-protected MCP server. Descope matches the assertion's subject to the user in the matching tenant, and mints an access token for your server.

This works the same whether the XAA token came from Okta, Ping, or any other workforce IdP the customer uses that supports Cross App Access / ID-JAG.

Access goes through Descope firstReplay

Presenting ID-JAG to Descope…

1. The MCP client presents the customer's ID-JAG to Descope (the authorization server for your MCP server).
2. Descope validates it, matches the subject to the tenant user, and returns a Descope access_token.
3. Only then does the client call your MCP server with that token. Your server never sees the ID-JAG.

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 Cross-App Access 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.

Cross-App Access is part of the tenant's SSO configuration, because the assertions you accept come from the same workforce IdP the tenant already signs in with. It reuses the JWT Bearer grant: you add the issuer's URL and keys, 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.

Two Ways to Configure XAA

The configuration can be written either by you or by the customer, and both produce the same tenant settings:

The Setup Suite path is usually what you want for a B2B product, since the customer configures Cross-App Access for their own organization in the same session where they set up SSO, without a support ticket.

Turning it on

In the Console, open the tenant, go to Authentication Methods → SSO, and select the Cross-App Access tab. Enable Allow Cross-App Access (ID-JAG), which is off by default. Turning it on reveals the sections below.

The tab has three parts, and they run in order.

• Resource Server Details gives you values to hand to the customer.
• Trusted Issuer is where you accept their IdP.
• JIT Provisioning decides how their users become users in your project.

Resource Server Details

This section is read-only.

It shows the two values that identify your resource server to the customer's IdP, and the customer copies both into the cross-app access configuration on their side.

Together the two values are what keep customers separated. aud says the assertion is for your project, and aud_tenant says which customer inside it.

An ID-JAG minted for one tenant cannot be redeemed against another.

Trusted Issuer

Which IdP Descope accepts assertions from, and how it verifies their signatures.

An ID-JAG is only worth as much as the issuer behind it, so this is the setting that carries the trust. The customer gives you their IdP's issuer URL, and Descope uses it two ways. It is the value every incoming assertion's iss claim has to match, and it is where Descope fetches the public keys that verify the assertion's signature.

On each incoming assertion Descope then checks that the signature verifies against those keys, that iss is the issuer registered on this tenant, that aud matches the Audience you configured, and that the assertion has not expired. An assertion that fails any of these is rejected and no access token is issued.

Registering the issuer on a specific tenant is what keeps customers apart. An assertion is only ever evaluated against the issuer configured for the tenant it targets, so an ID-JAG minted by one customer's Okta cannot buy access anywhere else in your project no matter how valid its signature is.

A tenant can trust more than one issuer. The + Add issuer button at the bottom of the section adds another set of these fields, which is what you would use when a customer runs more than one IdP, or is midway through moving between them. Descope accepts an assertion if it matches any issuer configured on the tenant.

JIT Provisioning

The assertion names a subject, but that subject is a user in the customer's directory, not yet a user in yours. Something has to create the Descope user record that the access token is eventually issued for, and you have two ways to do it.

Enable JIT Provisioning is a toggle that creates and updates that user from the claims in the ID-JAG, every time one validates. The first time a given employee's agent calls your server the user appears in the tenant, and later assertions keep their attributes current. Nothing has to be set up in advance, which is why JIT is the quicker path to a working integration.

With the toggle off, provisioning and mapping have to happen some other way, in practice through SCIM.

Leaving it off means the exchange only succeeds for users who already exist in the tenant.

Choosing between JIT and SCIM

The tradeoff is not about how users get created. It is about what happens when they leave.

JIT only ever hears about a user when that user shows up. It has no channel for the opposite event. When an employee leaves the company and their IdP account is disabled, their agent stops being able to obtain new ID-JAGs, but the Descope user record you created from an earlier assertion stays active, and so does any Descope session already issued for it.

SCIM is the channel for that event. The customer's IdP pushes the deactivation, Descope marks the user inactive, and the next time that user's session tries to refresh, the refresh fails and access ends. That is what makes SCIM the right answer for enterprise customers who expect offboarding in their directory to actually revoke access to your product.

So: enable JIT when you do not manage that tenant's users with SCIM, and it is the reasonable default for getting a customer running.

When SCIM provisions the tenant's users, leave JIT off and let SCIM own the user record, so that the lifecycle events you care about arrive through the same channel that created the user.

User Attribute Mapping

This is the same attribute mapping you already know from SSO, with one difference in where the values come from. Instead of reading a SAML assertion or an id_token, you are mapping claims carried on the ID-JAG onto Descope user attributes.

It matters most when the customer's IdP sends custom claims in the assertion that you want reflected on the user profile, since JIT builds the user from exactly these claims.

Group Attribute Mapping

Here you enter the name of the claim that carries group association, commonly groups. Descope reads group names out of that claim on the ID-JAG and maps them onto the tenant's groups.

This lets a customer's existing IdP group membership drive access without a separate assignment step in your product.

Setup Instructions