What Is a Bearer Token? – Definition and How It Works
Learn what a bearer token is, why possession alone grants access, how JWTs differ from opaque tokens, and how to handle them safely.
A bearer token grants access to whoever presents it. There is no second factor, no binding to a device, and no proof of ownership — possession is the whole authorisation.
1. How It Is Sent
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
The server validates it and, if valid, treats the request as coming from whoever the token represents.
2. Why "Bearer" Is the Important Word
The token is like cash. Anyone holding it can spend it, and the server cannot distinguish the legitimate holder from someone who intercepted it.
Three consequences follow directly: it must travel only over TLS, it must never be logged or placed in a URL, and it should be short-lived so a leak has a bounded window.
3. Opaque Versus Structured
| Aspect | Opaque token | JWT |
|---|---|---|
| Content | A random identifier | Encoded claims plus a signature |
| Validation | Look up server-side | Verify the signature locally |
| Revocation | Immediate — delete the record | Hard — valid until expiry unless a list is kept |
| Size | Small | Larger, and sent on every request |
| Readable by the client | No | Yes — encoded, not encrypted |
That last row is misunderstood constantly: a JWT's payload is base64-encoded and readable by anyone holding the token. It must never contain secrets.
4. Access and Refresh
The usual arrangement pairs a short-lived access token with a longer-lived refresh token. The access token is sent with every request and expires quickly; the refresh token is stored more carefully and exchanged for a new access token when needed.
This bounds the damage from a leaked access token while avoiding a login on every expiry.
5. Validating One
A server should check the signature against the expected key, the expiry, the issuer, the intended audience, and any scopes the operation requires.
Skipping audience validation is a common flaw: a token issued for one service is accepted by another, which was never its intended recipient.
6. Storing One in a Client
- Never in a URL, since URLs appear in logs, history, and referrer headers.
- Never in code or version control.
- In memory where possible; in secure storage where persistence is required.
- In browsers, a
HttpOnlycookie limits exposure to injected scripts, at the cost of needing cross-site request protections.
7. Revocation Is the Weak Point
A structured token that validates locally cannot be withdrawn before it expires unless the server maintains a denial list — which reintroduces the lookup that local validation was meant to avoid.
Short lifetimes are the usual compromise: minutes rather than days, so a compromised token stops working quickly.
8. Summary
A bearer token authorises whoever presents it, sent in an Authorization header, either opaque and looked up or structured and verified locally.
Treat it as cash: TLS only, never in URLs or logs, short-lived, validated for signature, expiry, issuer, audience, and scope — and remember a JWT's contents are readable by anyone who holds it.