Bearer tokens and API authentication

In short: A bearer token is an access key that a client sends in the header with every API request: Authorization: Bearer <token>. Whoever possesses the token (“bearer” = holder) has access.

In more detail: The token is issued after login. The server checks on each request whether it is valid and so knows who is asking, without transmitting password and session every time.

In Depth

• Kinds: Random opaque strings that the server looks up, or self-contained tokens such as JWT that contain data and signature.
• OAuth: The access token (OAuth 2.0) is usually a short-lived bearer token, complemented by a refresh token used to fetch a new one.
• Risk: Anyone who has the token can use it. So send only over HTTPS, short validity, limit rights (scopes), do not write into URLs or logs.
• Storage in the browser: localStorage can be read via XSS, an HttpOnly cookie cannot (but needs CSRF protection). See XSS and CSRF.
• Revocation: Opaque tokens can be blocked server-side. Pure JWTs are valid until expiry unless you keep a deny list.
• Alternatives: API keys (long-lived, for servers), session cookies (for browser pages), mTLS.

See also: two-factor login