What Is a Bearer Token? A Practical Guide to Bearer Authentication

A bearer token is a string that grants access to whoever “bears” it — no username, password, or extra proof of identity required. Whoever holds the token can use it, which is exactly what makes it simple and exactly what makes it worth handling carefully.

How Bearer Tokens Work

Bearer tokens travel in the Authorization HTTP header, prefixed with the word Bearer:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The server checks the token against whatever issued it (a session store, a JWT signature, an OAuth provider) and, if valid, treats the request as coming from whoever the token represents. This is defined by RFC 6750, the OAuth 2.0 Bearer Token Usage spec, though bearer tokens show up outside OAuth flows too — plenty of APIs issue a bearer token directly at login without a full OAuth dance.

Bearer Tokens vs. API Keys vs. Basic Auth

All three go in a header, but they mean different things:

• Basic auth sends a base64-encoded username:password pair on every request. Simple, but the credential is your actual password.
• API keys are typically long-lived, often tied to a project or app rather than a specific user session, and rarely expire on their own.
• Bearer tokens are usually short-lived and tied to a login or authorization event — an access token from an OAuth flow, a JWT issued at sign-in, or a session token. They’re built to be rotated and to expire.

If your API issues a token after a login step and expects it back on every subsequent request, that’s bearer auth, even if the token itself isn’t a JWT.

Where Bearer Tokens Come From

Three common sources:

1. OAuth 2.0 access tokens — issued by an authorization server after a user grants access, often alongside a refresh token used to get a new access token once the old one expires.
2. JWTs (JSON Web Tokens) — self-contained tokens carrying claims (user ID, expiry, scopes) that a server can verify without a database lookup, by checking the token’s signature.
3. Plain session tokens — an opaque string issued at login and looked up server-side on every request. No cryptographic structure, just a reference into a session store.

All three get sent the same way: Authorization: Bearer <token>.

Common Pitfalls

• Treating expiry as optional. A bearer token that never expires is a permanent credential with none of the protections a password reset gives you. Short-lived tokens plus a refresh flow are worth the extra complexity.
• Logging the token. Authorization headers routinely end up in request logs, error trackers, or browser history if the token is ever put in a URL. Treat it like a password in transit.
• Storing it insecurely client-side. localStorage is readable by any script on the page, which makes token-stealing via XSS straightforward. An httpOnly cookie or in-memory storage closes that gap at the cost of some flexibility.
• Skipping HTTPS. A bearer token sent over plain HTTP is trivial to intercept. There’s no partial credit here — it has to be TLS.

Testing Bearer Token Auth

When you’re building or debugging an API that uses bearer auth, you want to set the header once per environment and stop thinking about it. HTTP Titan’s Auth tab supports Bearer tokens directly on a request or an entire collection, including environment-scoped variables so a token can differ between local, staging, and production without editing the request itself.