Bearer Token
SecurityDefinition
A bearer token is an access token type where possession of the token is sufficient for authentication ("bearer" means whoever holds it can use it. Bearer tokens are used in OAuth 2.0 and are sent in the Authorization header: "Authorization: Bearer <token>". JWTs are commonly used as bearer tokens.
How Bearer Token Authentication Works
The OAuth 2.0 authorization framework, published as RFC 6749 on 2012-10-01, defines the bearer token as the primary access token type. Possession equals authorization. The flow works in stages: the client first authenticates with the authorization server using a grant type such as password, client credentials, or authorization code, then the server issues a bearer token carrying a defined scope and expiration time, and finally the client includes that token in every subsequent API request via the Authorization header, formatted as "Authorization: Bearer eyJhbGc..." where eyJhbGc is the beginning of a base64url-encoded JWT header. The resource server then validates the token by looking it up in a database (opaque tokens) or verifying its cryptographic signature (JWTs). Bearer tokens replace session cookies in stateless APIs. Stateless means the server holds no session. Any server instance can validate a token independently, which makes horizontal scaling straightforward and eliminates the need for session-affinity routing. Token lifetime is a security trade-off: short-lived tokens (15 minutes) minimize damage if stolen, while refresh tokens allow getting new access tokens without forcing the user to re-authenticate.
JWTs as Bearer Tokens
JSON Web Tokens (JWTs) are the most common bearer token format in modern APIs. A JWT consists of three base64url-encoded parts joined by dots in the format header.payload.signature, where the header declares the signing algorithm (RS256 for asymmetric RSA or HS256 for symmetric HMAC), the payload carries standard claims including sub for the user identifier, iat for issued-at time, exp for expiration, and scope for the granted permissions, and the signature is computed over the first two parts using either the server private key (RS256) or a shared secret (HS256). Self-contained. No database needed. The resource server verifies the signature cryptographically on every request, which eliminates the database roundtrip that opaque tokens require and makes JWT validation fast at any scale. The downside is revocation: a revoked JWT stays valid until its exp claim elapses, because there is nothing to check. Best practice is to keep JWT expiry short (15 minutes), pair access tokens with longer-lived refresh tokens, and maintain a token denylist in Redis for critical revocations such as account compromise. Libraries like jsonwebtoken (Node.js) and PyJWT (Python) handle all signing and verification correctly.
Bearer Token Security Best Practices
Storage matters. Store tokens in memory as JavaScript variables or in secure HttpOnly cookies. Never store tokens in localStorage because it is accessible to any JavaScript on the page, making it trivially vulnerable to cross-site scripting attacks where injected scripts can exfiltrate the token and reuse it from any origin. Always use HTTPS. Bearer tokens are encoded, not encrypted, so anyone who intercepts the traffic can read and reuse them. Validate on every request: check the signature, the expiry claim (exp), the audience claim (aud), and the issuer claim (iss). Use rotation. Issue short-lived access tokens (15 minutes) paired with longer-lived refresh tokens (7 days). Rotate refresh tokens on each use so that if a refresh token is stolen and used, the original holder presenting the invalidated token triggers a reuse-detection alarm. Set minimum scope. Grant only the permissions the client actually needs for the operation it performs. Log every token issuance and revocation event for auditing and incident response. When implementing OAuth for public clients such as mobile apps or single-page apps, always use PKCE (Proof Key for Code Exchange) and validate the state parameter on the redirect callback to prevent CSRF attacks that could hijack the authorization flow.
Related Tools
Frequently Asked Questions
Related Terms
JWT
JSON Web Token (JWT) is an open standard (RFC 7519) for securely transmitting information between parties as a JSON object. JWTs are self-contained tokens composed of three Base64URL-encoded parts: header, payload, and signature. Widely used for authentication and API authorization.
OAuth
OAuth 2.0 is an authorization framework that allows applications to obtain limited access to user accounts on HTTP services. OAuth enables "Login with Google/GitHub" flows where a third-party app is granted access to specific user data without receiving the user's password.
API Key
An API key is a unique identifier string passed in requests to authenticate an application or user accessing an API. API keys are simpler than OAuth but provide less security; they are long-lived, not scoped per-user, and must be kept secret.
SSL/TLS
SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols that provide encrypted communication over the internet. TLS is used in HTTPS, email (SMTP/IMAP), VPNs, and any application requiring secure data transmission. SSL is deprecated; TLS 1.3 is current.