Lion Cipher Lab
Delegate without handing over the keys: OAuth 2.0 Token Exchange (RFC 8693) in Keycloak
- Identity & Access Management
- Intermediate
- ~60 min
- Free · no account required
Why it matters
Almost every real system is a chain, not a single hop. A user logs into a web app; the web app calls an orders API; the orders API needs to ask a billing API something. The user's access token — the small credential that proves 'this request is allowed' — arrives at the orders API, and now a developer has to decide what to send onwards. Two answers come naturally and both are quietly dangerous. The first is to FORWARD the same token: cheap, works immediately, and it means the billing API now holds a credential that also opens the orders API, the reporting API, and anything else that token was…
What you'll learn
- recognising the confused-deputy problem in a chain of APIs that forward one access token
- why an over-broad audience (aud) claim is a real vulnerability and not a style complaint
- running the RFC 8693 token exchange grant by hand with curl against a live Keycloak
- reading the request parameters: subject_token, subject_token_type, requested_token_type, audience, scope
- decoding a JWT payload from the command line and diffing aud, azp, scope, sub and exp across two tokens
- the difference between delegation (act claim) and impersonation (no act claim), and why delegation is the safer default
- what may_act is for, and how a policy control decides who is allowed to exchange at all
- configuring an audience mapper in Keycloak, and why the audience parameter FILTERS rather than adds
- producing deliberate failures so you can see the authorization control refuse an exchange
- knowing when NOT to exchange — where client credentials or a plain refresh is the correct tool
Steps in this lab
- The problem, before any of the vocabulary
- The vocabulary of an exchange: subject, actor, delegation, impersonation
- When NOT to exchange (read this before you build anything)
- Version reality check: two token exchanges live in Keycloak, and they are not the same
- Check your tools, then start Keycloak on a pinned image
- Build the three-service world: one realm, three clients, one user
- Wire the audiences — and learn why the audience parameter filters instead of adds
- Set up your shell and get the user's token (the subject token)
- Perform the exchange with curl
- Diff the two tokens — this is the whole lesson in four claims
- Break it on purpose, twice: watch the exchange get refused
- Where is the act claim? Spec versus implementation, honestly
- The pro move: combine narrowing with sender-constraining
- Tear it down