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. Choose Delegation (attaches act) or Impersonation (no act) via the studio semantics toggle; use Policy & Access to tune audience narrowing, max act depth, and allowed clients, then re-run evaluation.
  3. Open the ID-JAG / XAA tab for Cross-App Access, RFC 8693 / 7523 for protocol workbenches, or MCP / Agents for agent identity chaining. Flip to Live Server when real backends are ready.

Frequently asked questions

Are tokens stored on stbox 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 the difference between Delegation and Impersonation?

Per RFC 8693 §2.1, Delegation keeps the end-user in sub and attaches an act (actor) claim so SIEM can tell the calling client from the user. Impersonation issues a token that looks like the user alone — no act footprint — and should be limited to privileged admin clients. stbox shows a warning when Impersonation is active and Virtual Sandbox traces omit act accordingly.

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.