IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Token exchange — delegation across services
Maya asks an app to email her a report. The app must call a separate reports service to get the data. Which credential should it show that service? Your goal: explain why forwarding a token is wrong and what token exchange does instead.
- Do not forward Maya's token to another service.
- Forwarding gives the wrong audience, too much power and a false log.
- Token exchange trades her token for a new one made for the next service.
- The new token keeps sub as Maya and adds act for the app.
- Use it at every hop in a chain and for AI agents.
The shortcut: forward Maya's token
When Maya signs in, the app gets an access token. The tempting move is to forward that same token to the reports service. But the token was made for the app, not for the reports service. Forwarding breaks three things.
| What breaks | Why forwarding fails |
|---|---|
| Wrong audience | Every token names its intended receiver in an audience (aud) claim. Maya's token says aud: app. The reports service should refuse any token not addressed to it. |
| Too much power | Maya's token may carry every scope the app was granted. The reports call needs one narrow permission. |
| The audit log lies | The token says sub: maya and nothing more. So the log says "Maya called". The app, which really made the call, is invisible. |
The honest way: token exchange
Token exchange (RFC 8693) is a standard OAuth request. The app gives Maya's token to the IdP as a subject_token. It asks for a new token made for the reports service. The IdP returns a token with the right audience and the smallest scope. It also records who is really calling.
sub: maya (whose data and whose request it is). It adds act: {sub: app}, the actor claim that names who is really on the wire. It also has a tight audience and scope.The new part is the actor claim. The sub claim still says Maya, because it is her data. The act claim names the app as the caller. Now the log says: "the app, acting for Maya, read report 4411".
Delegation or impersonation
Delegation means the app acts for Maya and says so. Both identities show in the token. Impersonation means the app pretends to be Maya. Only her identity shows. Forwarding her raw token is impersonation by accident.
a signed letter that says "Acting for Maya" versus Maya's own ID card in your pocket. With the letter, everyone knows you are an agent. With the ID card, every clerk thinks you are Maya.
Chains and agents
A request may pass through many microservices. Each hop should trade down to exactly the audience and scope the next one needs. Never pass a big token deeper. AI agents need this too. When Kai the agent calls a tool for Priya, the token must name both of them. That is the on-behalf-of pattern from the AI agents lesson. Exchange can also ask for a narrower scope, which enforces the ideas of the scopes lesson.
Forwarding a token invites the confused deputy problem. That happens when a service with broad power is tricked into using it for the wrong caller. A forwarded token also carries more power than the job needs. Exchange shrinks power at every hop and keeps the log honest.
Go deeper: nested actors and an audit story
If a third service joins the chain, the act claims nest. The whole call path is recorded.
Picture an auditor who asks, "Who read customer 4411's revenue?" With a forwarded token, the log says Maya did. But Maya never touched the reports service. The app did, for her, and the token could not tell the difference.
Now play it. The lab runs the exchange step by step. Then it breaks it three ways: a forwarded token, an app with no right to act and a token for the wrong API. After that, you build the exchange yourself.
🧪 Interactive lab — enable JavaScript to play with this one.
Compose an RFC 8693 exchange and watch the act claim take shape with Token Exchange. Grade a trust policy for confused-deputy risk with IAM Trust Check.