JWTs and Bearer Tokens

Being able to read a token's contents does not establish that an API should accept it. Consider an engineer inspecting an access token that ReadShelf sends to the bookstore API. They decode it, find a customer identifier and a permission, and assume the request is safe to process. Adding a signature check still leaves a possible problem: the authorization server may have issued the token for a different API.

A useful token design must distinguish what a credential contains, how a caller presents it, and which checks make it acceptable for a particular request.

This chapter explains JWT structure, bearer-token usage, validation boundaries, and the trade-offs between locally validated JWTs and opaque tokens.

The examples use a fictional bookstore API over HTTPS. Its authorization server issues signed JWT access tokens for ReadShelf to read a customer's private lists. The bookstore uses the standardized JWT access-token profile, with a configured issuer, API audience, and signing algorithm. Scope names, endpoint paths, and token lifetimes are application choices.