Token Exchange & Delegation Studio

Test ID-JAG (Cross-App Access / XAA), RFC 8693 Token Exchange, RFC 7523 JWT Grants, and AI Agent (MCP) delegation flows.

Privacy: Client-Direct + Server-Proxy. Prefer browser fetch() to the IdP. On CORS failure or confidential clients, fall back to /api/v1/proxy/token. Credentials and assertions are not retained.
Loading Token Exchange Studio…

What is token exchange & ID-JAG?

OAuth 2.0 Token Exchange (RFC 8693) lets a client trade a subject token for a new token scoped to a different audience or with an actor (delegation) claim. Cross-App Access / ID-JAG builds on that: an enterprise IdP issues a short-lived Identity Assertion Authorization Grant (typ oauth-id-jag+jwt), which a resource authorization server exchanges via RFC 7523 JWT Bearer for an access token.

Agentic AI and MCP servers use the same patterns so an LLM host can call tools on behalf of a user with short-lived delegated tokens instead of static master API keys.

How to use this tool

  1. Open Simulate & Inspect (Virtual Sandbox) and Run Simulation to walk OIDC → ID-JAG → JWT bearer → API with inspectable HTTP and cURL/Node/Python exports — no external IdP required.
  2. For ID-JAG / XAA, Phase 1 is RFC 8693 Token Exchange with requested_token_type=id-jag; audience (Resource AS issuer) is required and actor_token is optional (draft leaves actor processing undefined). Phase 2 is RFC 7523 JWT Bearer at the Resource AS.
  3. For generic RFC 8693 microservice exchange, choose Delegation (requires actor_token, attaches act) or Impersonation (no act). Use Policy & Access to tune teaching rules, then re-run evaluation.
  4. Open the ID-JAG / XAA, RFC 8693 / 7523, or MCP / Agents tabs. Flip to Live Server when real backends are ready.

Frequently asked questions

Are tokens stored on Utilxo servers?

No. Calls run from your browser. The optional token proxy relays the request in memory and does not persist credentials or responses.

What is ID-JAG / Cross-App Access (XAA)?

Per draft-ietf-oauth-identity-assertion-authz-grant, an IdP issues a short-lived Identity Assertion JWT Authorization Grant (typ oauth-id-jag+jwt) via RFC 8693 Token Exchange. The Resource Authorization Server then exchanges that JWT via RFC 7523 JWT Bearer for its own access token. Required Phase 1 parameters include audience (Resource AS issuer), subject_token, and subject_token_type; actor_token is optional and not required.

Is actor_token required for ID-JAG?

No. The ID-JAG draft marks actor_token as OPTIONAL and does not define normative processing or whether an act claim is issued. Client identity for the grant is carried in the required client_id claim. Utilxo never requires actor_token for ID-JAG Phase 1; an advanced optional field exists only for experimental teaching.

What is the difference between Delegation and Impersonation?

Per RFC 8693 §2.1 (generic token exchange), Delegation keeps the end-user in sub and attaches an act (actor) claim so SIEM can tell the calling client from the user; that profile requires actor_token. Impersonation issues a token that looks like the user alone — no act footprint — and should be limited to privileged admin clients. For ID-JAG specifically, XAA already identifies the client via client_id; the studio semantics toggle may attach an experimental act claim in Virtual Sandbox for teaching but never forces actor_token.

What does the Policy & Access tab evaluate?

It is a client-side teaching inspector (Keycloak/Okta/OPA style), not your production IdP. It never blocks token-endpoint calls — only the IdP enforces allow/deny. In Virtual Sandbox it shows an advisory ALLOWED/DENIED checklist (client authz, impersonation privilege, audience narrowing, scope boundary, max act depth). Edits persist for the browser session (sessionStorage); use Reset to defaults to restore the stock teaching policy.

What is the MCP / Agents tab for?

It is a teaching and dry-run surface for agentic identity chaining — how an AI agent host obtains a short-lived delegated token (with act claims) so an MCP server can call APIs on behalf of a user without storing static master API keys. Click actors in the diagram to see each hop; in Virtual Sandbox you can mint a user ID token and run a virtual agent exchange. It is not a policy or rules engine, does not configure MCP tools, and does not automatically inherit results from the ID-JAG, RFC 8693, or RFC 7523 tabs unless you paste tokens yourself.

How does MCP / Agents relate to the other tabs?

The studio is four views of related OAuth patterns: ID-JAG / XAA for cross-app access, RFC 8693 for generic token exchange (including actor/act chains), RFC 7523 for jwt-bearer assertion grants, and MCP / Agents for the same ideas shaped as User → Agent Host → IdP → MCP → API. Agent flows usually rely on RFC 8693-style exchange; use Simulate & Inspect with the MCP scenario for a full 4-hop HTTP trace, or the MCP tab for mint helpers and hop explanations.

What is /id-jag?

A short alias that redirects to /token-exchange?tab=id-jag for Cross-App Access workflows.