Cybersecurity glossary
What is a Bearer Token?
Learn what a bearer token is, how OAuth and APIs accept whoever presents the token, why theft enables replay, and how sender-constrained tokens and short lifetimes reduce risk.
Definition
A bearer token is an access credential that grants authority to any party who possesses it; the resource server typically does not require additional cryptographic proof that the presenter is the legitimate client that received the token.
Why “possession equals authority” matters
In many API designs, presenting a valid access token is enough. That convenience is the defining property of a bearer token: the resource server does not require the caller to prove they are the original recipient—only that they hold the secret string.
Bearer tokens power most OAuth deployments. They also concentrate risk wherever tokens can be copied.
How bearer access works
Client obtains a token
Usually via an OAuth grant such as authorization code or client credentials.
Client calls the API
Sends Authorization: Bearer <access_token> over TLS to the resource server.
Resource server validates
Checks signature or introspection, audience, issuer, expiry, and scopes.
Request authorized
If valid, the API performs the action within the token’s permissions.
Theft enables replay
Anyone who copied the token can repeat steps 2–4 until expiry or revocation.
Bearer tokens vs stronger bindings
| Model | What proves authority | If token is stolen |
|---|---|---|
| Bearer token | Knowledge of the token value | Attacker can call APIs directly |
| mTLS-bound token | Token + client TLS certificate | Harder without the private key |
| DPoP-bound token | Token + DPoP key proof per request | Replay without key fails |
| Cookie session (HttpOnly) | Browser-held cookie, not script-readable if set well | XSS impact reduced vs JS-readable tokens |
Where bearer tokens leak
Browser storage
Tokens in localStorage are easy prey for XSS.
Logs and analytics
Authorization headers accidentally written to SIEM or APM.
Referrers and URLs
Tokens placed in query strings appear in history and logs.
Mobile backups
Unencrypted app storage or screenshots expose secrets.
Proxy tooling
Shared debug captures include live bearer credentials.
Malicious extensions
Browser add-ons read pages and headers on compromised profiles.
Hardening checklist
- Issue short-lived access tokens; rotate refresh tokens and detect reuse.
- Transmit tokens only over TLS; never put them in URLs.
- Strip Authorization headers from logs, error reports, and third-party analytics.
- Prefer memory or secure storage patterns appropriate to the client platform.
- Validate audience, issuer, expiry, and scopes on every resource-server request.
- Revoke quickly on logout, compromise, or client deprovisioning.
- Use sender-constrained tokens (DPoP or mTLS) for high-value APIs.
- Monitor for token use from anomalous networks or impossible travel patterns.
Choosing when bearer is acceptable
Bearer tokens remain reasonable for many lower-risk APIs when lifetimes are short, storage is careful, and blast radius is limited by scopes. As impact rises—admin APIs, payments, health data—pair OAuth with proof-of-possession.
The practical takeaway
A bearer token authorizes whoever holds it. That simplicity speeds integration and magnifies theft.
Treat bearer access tokens as valuable secrets: minimize lifetime and scope, prevent leakage, and upgrade sensitive traffic to sender-constrained designs whenever the risk justifies the complexity.
Related security terms
OAuth 2.0
Framework that commonly issues bearer access tokens.
Sender-Constrained Token
Tokens that require proof of possession beyond mere presentation.
OAuth Token Theft
Attacks that steal bearer tokens from clients, logs, or browsers.
Token Replay
Reuse of captured tokens against APIs until expiry or revocation.
Demonstrating Proof of Possession (DPoP)
A mechanism to sender-constrain OAuth tokens.
Frequently asked questions
What is a bearer token in simple terms?
It is like a concert wristband: whoever holds it gets in. APIs that use bearer tokens trust the credential itself, not an extra proof of who is holding it.
Where do bearer tokens appear?
Most often as OAuth 2.0 access tokens in the HTTP Authorization header: Authorization: Bearer <token>.
Why are bearer tokens risky?
If stolen from browser storage, logs, mobile devices, or network traces, an attacker can call APIs as the victim until the token expires or is revoked.
Are all JWTs bearer tokens?
Many JWT access tokens are used as bearer tokens, but JWT is a format. A token can be JWT-shaped and still be sender-constrained with mTLS or DPoP.
How do you protect bearer tokens?
Use short lifetimes, refresh-token rotation, TLS everywhere, avoid localStorage for browsers when possible, never log tokens, and prefer sender-constrained tokens for sensitive APIs.
What replaces pure bearer tokens?
Sender-constrained approaches such as mTLS-bound tokens and DPoP require the caller to prove possession of a key associated with the token.
Should refresh tokens be bearer tokens?
Refresh tokens are often bearer credentials too and need even stricter storage, rotation, and binding because they mint new access tokens.
References
Explore authoritative guidance and frameworks related to bearer token.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.