Token Exchange (RFC 8693) — Primer

Why it matters

Standards reduce risk and vendor lock‑in. We implement this spec across our Studios and runtime so policy is portable.

Where it’s enforced

• Gateway: pre‑execution gating (plan/schema pins, params/egress)
• Shield: inline budgets/stream caps/content checks
• PDP: decisions with constraints/obligations/TTL
• IdP: passports, token exchange, consent/DPoP

How it works (high level)

RFC 8693 lets a client exchange one token for another. Inputs include subject_token (required), optional actor_token, and requested_token_type. The AS validates inputs and issues a new token; for OBO, JWTs commonly carry act (actor) and may include may_act.

x-www-form-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:token-exchange&
subject_token=...&
subject_token_type=urn:ietf:params:oauth:token-type:access_token&
actor_token=...&
actor_token_type=urn:ietf:params:oauth:token-type:access_token&
requested_token_type=urn:ietf:params:oauth:token-type:access_token&
resource=https://api.example.com/

mermaid
sequenceDiagram
  autonumber
  participant C as Client
  participant AS as Authorization Server (TE)
  participant RS as Resource Server
  C->>AS: POST /token (TE: subject_token[, actor_token])
  AS->>AS: Validate signatures/expiry/audience/types
  AS-->>C: access_token (may include act.sub; aud set for resource)
  C->>RS: Use new token to call API

Key params: subject_token[_type], actor_token[_type], requested_token_type, resource (or AS-specific audience), scope. Output is a normal OAuth token response.

References

• RFC 8693: OAuth 2.0 Token Exchange