Use an access token in a Bearer header.

A protected application programming interface (API) should not need the user’s main password every time a client calls it. Bearer access tokens solve that problem by giving the client a separate credential that represents approved access. The API can accept that token without learning the user’s password.

The word bearer describes the security property: possession is enough. If a client has a valid bearer token, it can present the token in the Authorization header and request the access that token allows. The API must still validate the token’s issuer, audience, time limits, and permissions before trusting it.

Bearer tokens are useful because they can be narrower and shorter-lived than a primary sign-in credential. One token might be valid only for the Orders API and only for reading orders. That limits how much authority a client needs to carry.

The tradeoff is theft. If an attacker copies a bearer token, the attacker may be able to replay it until it expires or is revoked. Hypertext Transfer Protocol Secure (HTTPS), careful storage, and log hygiene are therefore essential. Later lessons add sender constraints so a copied token is not enough by itself.