Enterprise-Managed Authorization: Cross App Access, ID-JAG, and CIMD for B2B SaaS

This guide is for B2B SaaS teams whose enterprise customers now ask a new question. "Our employees use AI agents. Can those agents call your API or MCP server, under our IdP's rules, without every employee clicking through an OAuth consent screen?" The answer the market is converging on has three names and two specs. This page untangles them and lists what you have to build.

What Enterprise-Managed Authorization is

Three labels describe the same mechanism:

"Enterprise-Managed Authorization" as an industry-wide umbrella term is early. It is MCP's extension name, and Auth0 uses it too. Expect the vocabulary to keep moving. The wire protocol is what to anchor on.

The problem it solves

B2B SaaS apps already have three ways to let one piece of software reach another on a user's behalf. Each one breaks down when an enterprise brings AI agents.

Per-user OAuth consent sprawl. Every employee who connects an agent to your app runs an authorization code flow and clicks "Allow". The enterprise admin sees none of it. There is no central place to say "Agent X may reach App Y, read-only, for the finance group." Offboarding an agent means finding every grant.

Static API keys. The fallback when OAuth feels heavy. A key pasted into an agent config has no user binding, no expiry, and no policy behind it. Okta's Oktane 2026 announcement framed Agent SSO as exchanging exactly these non-expiring keys for short-lived, identity-governed tokens.

Dynamic Client Registration sprawl. Earlier MCP spec versions (2025-03-26 and 2025-06-18) leaned on Dynamic Client Registration. Every agent instance registers itself, so your authorization server accumulates clients it cannot identify. The MCP Server Identity Model guide covers how open DCR became the default risk.

None of these let the customer's security team apply the policy they already run for workforce SSO. That is the gap.

The two layers: CIMD and ID-JAG

Enterprise-Managed Authorization answers two separate questions. Keep them apart in your head and in your code.

Layer 1: which software is this? CIMD. A Client ID Metadata Document makes the OAuth client_id an HTTPS URL. That URL serves a JSON document describing the client: its name, its redirect URIs, its public keys. Any authorization server can fetch it. No registration call is needed. CIMD is draft-ietf-oauth-client-id-metadata-document-02 (6 Jul 2026). The MCP authorization spec dated 2025-11-25 says authorization servers and clients SHOULD support it. For the background on why CIMD replaces DCR in MCP, read CIMD: the future of MCP authentication.

Layer 2: may this software act for this user, here? ID-JAG. The customer's IdP evaluates admin policy and, if allowed, signs a short-lived JWT. That JWT names the user, the requesting client, and the target authorization server. WorkOS describes the IdP as "the policy enforcement point: it mints the assertion only if the admin's policy allows that requesting app to reach that resource app for that user."

The two layers connect at one claim. Per WorkOS, "a client_id inside the ID-JAG is a CIMD identifier." So the ID-JAG says who is acting, and the CIMD URL in it says which software is acting. Your authorization server checks both.

The flow, step by step

Four parties take part:

• User: an employee of your enterprise customer.
• Requesting app: the AI agent or app that wants to call your API. Its client_id is ideally a CIMD URL.
• Enterprise IdP: the customer's identity provider. Your app already trusts it for that tenant's SSO.
• Resource app: your SaaS. It has an authorization server (resource AS) and an API or MCP server (resource server).

Step 0: the user signs in to the requesting app

The user logs in to the requesting app through the enterprise IdP with OIDC (or SAML). The requesting app now holds an ID token for that user, issued by the IdP.

Step 1: token exchange at the IdP

The requesting app calls the IdP's token endpoint using RFC 8693 token exchange. It sends the user's ID token as the subject_token and asks for an ID-JAG aimed at your authorization server.

POST /oauth2/token HTTP/1.1
Host: idp.customer.example
Content-Type: application/x-www-form-urlencoded
 
grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://auth.your-saas.example
&resource=https://api.your-saas.example/mcp
&scope=tickets.read
&subject_token=eyJhbGciOiJSUzI1NiIsImtpZCI6...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
&client_id=https://agent.vendor.example/oauth/client.json

Illustrative request. Hostnames, scope, and token are placeholders. The requesting app also authenticates itself to the IdP using whatever method the IdP requires.

The parameters that matter:

• grant_type: the RFC 8693 token exchange grant.
• requested_token_type: urn:ietf:params:oauth:token-type:id-jag. This is what makes it an ID-JAG request.
• audience: your authorization server's issuer identifier. The ID-JAG is only usable there.
• resource: optionally, the specific API or MCP server the token is for.
• subject_token: the user's ID token from the IdP. A SAML assertion is also allowed by the draft.

The IdP applies admin policy. It checks whether this requesting app may reach this resource app for this user, with these scopes. If not, it refuses. If yes, it mints an ID-JAG.

Step 2: the ID-JAG

The ID-JAG is a signed JWT with the header typ set to oauth-id-jag+jwt. That explicit type stops it being confused with an ID token or an access token.

{
  "header": {
    "typ": "oauth-id-jag+jwt",
    "alg": "RS256",
    "kid": "idp-signing-key-2026"
  },
  "payload": {
    "iss": "https://idp.customer.example",
    "sub": "00u8f2k1employee",
    "aud": "https://auth.your-saas.example",
    "client_id": "https://agent.vendor.example/oauth/client.json",
    "jti": "9f1c2e7a-3b4d-4c8e-a1f0-5d6e7f8a9b0c",
    "scope": "tickets.read",
    "iat": 1791206400,
    "exp": 1791206700
  }
}

Illustrative decoded ID-JAG. Values are invented; field set follows the draft's core claims. Note the five-minute lifetime.

Read it as a sentence. "The IdP at iss asserts that user sub, using client client_id, may get a token from authorization server aud with scope scope, once (jti), before exp."

Step 3: jwt-bearer grant at your authorization server

The requesting app sends the ID-JAG to your authorization server using the RFC 7523 JWT bearer grant.

POST /oauth/token HTTP/1.1
Host: auth.your-saas.example
Content-Type: application/x-www-form-urlencoded
 
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJ0eXAiOiJvYXV0aC1pZC1qYWcrand0IiwiYWxnIjoiUlMyNTYifQ...

Illustrative request. Client authentication to your AS is omitted for brevity.

Your authorization server must advertise that it accepts this grant. Put urn:ietf:params:oauth:grant-type:jwt-bearer in grant_types_supported in your RFC 8414 authorization server metadata. Clients look for it there.

Step 4: access token and the API call

Your authorization server validates the ID-JAG, maps the user to a local account in the right tenant, and issues its own short-lived access token. The requesting app calls your API or MCP server with that token. The IdP is not in the request path from here on.

No consent screen appeared at any point. The decision was made once, by the customer's admin, in the IdP.

What your SaaS (the resource app) must build

This is the side most B2B builders own. Most of the trust plumbing already exists in your enterprise SSO stack.

1. Trust the customer IdP per tenant. Reuse the SSO connection you already store on the Organization object. The issuer, JWKS location, and tenant mapping are the same facts your multi-tenant SSO setup holds. An ID-JAG from an IdP that is not configured for any tenant fails closed. Never accept an ID-JAG from an issuer just because it validates.

2. Validate every ID-JAG.

• Header typ is oauth-id-jag+jwt. Reject anything else.
• Signature verifies against the tenant IdP's published JWKS.
• iss matches the IdP configured for exactly one tenant.
• aud equals your authorization server's issuer identifier.
• client_id is a CIMD URL (or pre-registered client) you recognize and allow for that tenant.
• sub maps to a user already linked to that tenant through SSO. Do not JIT-create a user from an ID-JAG unless you have decided to, deliberately.
• exp is short and in the future. iat is recent.
• jti has not been seen before. Store it until exp passes to block replay.

3. Issue a short-lived, scoped-down access token. Grant the intersection of what the ID-JAG asked for and what your own policy allows for that user and client. Never widen scope beyond the assertion. Keep lifetimes short, because revocation at the IdP only stops new ID-JAGs. Token Management for AI Agents covers lifetime and sender-constraint choices.

4. Audit both identities. Every token issuance and every API call should log the agent client_id and the user sub, plus tenant, scopes, and the jti it came from. Without both, an incident review cannot separate "the user did this" from "an agent did this as the user."

5. Publish metadata. Advertise the jwt-bearer grant in grant_types_supported. If you run an MCP server, it must also publish RFC 9728 Protected Resource Metadata under the 2025-11-25 MCP spec.

What the requesting app must build

If you ship the agent or app that calls other SaaS apps, the work is on the other side.

• Sign users in through the enterprise IdP with OIDC so you hold an ID token to exchange.
• Publish a CIMD and use its URL as your client_id everywhere. The checklist below covers hosting.
• Run the token exchange at the IdP for each target resource app, with the right audience and resource.
• Run the jwt-bearer grant at each resource AS. Read its metadata first to confirm grant_types_supported includes jwt-bearer.
• Handle refusal cleanly. An IdP refusal is a policy decision, not an error to retry. Surface it to the user.
• Support the MCP extension explicitly if you are an MCP client. MCP extensions are optional and never on by default.
• Never pass tokens through. The MCP spec forbids token passthrough. Each resource gets its own token.

CIMD hosting checklist

These rules come from draft-ietf-oauth-client-id-metadata-document-02 and the MCP 2025-11-25 authorization spec.

The last row is the one teams miss. A desktop or CLI agent with a localhost redirect cannot prove it is the software named in the CIMD. In the enterprise-managed flow the IdP policy narrows that risk, but your authorization server should still treat such clients with care.

Where it fits against the alternatives

The MCP 2025-11-25 spec sets a client registration priority: pre-registered first, then CIMD when the AS metadata has client_id_metadata_document_supported: true, then DCR via registration_endpoint, then prompting the user. Enterprise-Managed Authorization sits on top of that. It changes who grants access, not how the client is named.

Vendor status as of 2026-10-05

This table reflects public announcements and docs only. Preview and early access features change. Verify every row in a proof of concept before you plan around it.

WorkOS noted that Okta, Auth0, and Descope moved within eight days of each other. That is fast convergence on a draft, which is a signal to prepare. It is not a signal that the draft is final.

Limitations and open questions

Both specs are drafts. ID-JAG is at -04 and CIMD at -02 as of this writing. Both are adopted by the OAuth WG, which means work continues and details can change. Pin the draft version you implement and track the datatracker pages.

The client has to support it. The MCP extension is optional and needs explicit client support. If the agent your customer uses does not implement the extension, the flow does not start.

The IdP has to support it. Your customer's IdP must issue ID-JAGs. If it does not, nothing you build on the resource side gets exercised. Ask your largest customers which IdP they run before you prioritize this.

Consumer CIAM is out of scope. The entire model rests on an enterprise IdP that you already trust for SSO and an admin who writes policy. A consumer app has neither. Consumer agent access still runs on OAuth consent. See Authentication for AI Agents for that side.

Revocation is split across two systems. Policy changes at the IdP stop new ID-JAGs. Access tokens your AS already issued live until they expire unless you revoke them. Short access token lifetimes are the practical answer today.

Scope translation is yours. The IdP decides at the app level. Mapping that decision onto your own scopes and object-level permissions is your job. Authorization Patterns for Agentic Workflows covers the per-action layer.

The deeper reason this matters is that agents do not carry passwords or sit through MFA prompts. The trust has to come from somewhere else, as argued in AI agents don't have passwords.

When to implement now and when to wait

If you buy rather than build, the decision is which CIAM provider already validates ID-JAGs on the resource side for your plan tier. Run that check in a POC against a real IdP tenant, not against the marketing page. For the broader agent identity stack this sits inside, see AI Agent Identity and MCP.