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

Request tokens for the application programming interface (API) that will actually receive them.

Scope says what access is requested; a resource indicator identifies where the client intends to use the token. The resource server must reject tokens not meant for it.

Why this lesson?

One client calls both an Orders application programming interface (API) and a Reports API. Each API should receive a token intended for that specific resource.

Learning goal and prerequisites
ONE NEW IDEA Distinguish scope from resource or audience, request a token for the intended protected application programming interface (API), and enforce the resource match when the token is used.
JWT validation showed how an API validates token claims. This lesson focuses on the audience/resource check that prevents cross-API token reuse.
Request sequence Authorization sequence
STEP 01

Identify the target resource

The client includes a resource parameter to tell the authorization server which protected resource it intends to call. This lets the server issue an access token with an audience and permissions appropriate for that resource.

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

One authorization server may issue tokens for several application programming interfaces (APIs). If a client requests a token without clearly identifying the target resource, the resulting credential may be too broad or may be sent to the wrong service. Resource indicators let the client ask for a token for a specific protected resource.

The client includes a resource identifier in the authorization or token request. The authorization server evaluates that target together with the requested permissions and issues a token intended for that resource. The token may carry an audience value that the receiving API can validate.

This is useful because a token for the Orders API should not automatically work at the Payments API. Narrowing the intended resource reduces the damage if a token is leaked and makes the trust boundary clearer for every service.

The client must still send the token only to the intended API, and the API must still validate the audience rather than assuming every token from the same issuer is acceptable. Resource indicators shape what token is issued; audience validation enforces that choice at the receiving resource.

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