Auth MechanicsAUTHENTICATION & AUTHORIZATION, FROM THE WIRE UP.
LESSON 34 OF 40

Exchange a token for access to another application programming interface (API).

The OAuth 2.0 Token Exchange standard lets a service request a token for another application programming interface (API) while identifying the user and the service acting for that user.

Why this lesson?

An Orders service acts for a user. It needs a separate token that the Inventory application programming interface (API) will accept.

Learning goal and prerequisites
ONE NEW IDEA Explain why a valid token may still be wrong for the next service, how OAuth 2.0 Token Exchange creates a token for a new audience, and why the exchanged token should preserve identities while narrowing authority.
Review the previous lesson if any of these terms are new. The link below opens that lesson.
Request sequence Authorization sequence
STEP 01

Request a token for another API

The service sends a subject token for the user and an actor token for the acting service. It also identifies the target audience. The token service authenticates the client and checks whether this exchange is allowed. How it trusts the actor token depends on the deployment.

Inspect request, response, and claims
Traffic inspector Examples only · not real requests
Try a failure scenario
↳ Change a condition
Read the detailed explanation
Key explanation
Why it exists, how it works, and where it fits
A token can be completely valid and still be the wrong credential for the next service. An Orders service may receive a token meant for itself and later need to call the Inventory application programming interface (API). Reusing the original token everywhere can expose authority to services that were never meant to receive it.
OAuth 2.0 Token Exchange lets a trusted component present one security token and request another token for a different resource or audience. The token service validates the original token, authenticates the requesting client when required, and checks policy before issuing anything new.
This is useful in multi-service systems because the new token can be shaped for the next boundary. It may have a different audience, a shorter lifetime, or a smaller permission set. The downstream API receives a credential intended for it instead of a broad credential that originated somewhere else.
The exchange should also preserve who is involved. A downstream service may need to know both the user whose authority is being used and the service acting for that user. Token exchange should narrow and translate authority, not quietly create new power that the original context did not justify.
Check your understanding
Lesson checkpoint
Pass the lesson quiz
Answer every question correctly to unlock the next lesson. Retry as often as you need.
Glossary Definitions of technical terms