What is a Bearer Token? OAuth 2.0, JWTs, Security

What is a bearer token?

A bearer token is a security credential used to authenticate API requests, defined in the OAuth 2.0 specification (RFC 6750). The defining characteristic is in the name: whoever bears the token is granted access — the token itself is the proof of authorization. There's no signature, no separate key, no challenge-response. Possession equals access.

Bearer tokens are the dominant authentication scheme for modern REST APIs and OAuth 2.0 flows. They replace older approaches like Basic Auth (which sends username + password on every request) and digest auth, providing a more flexible model that works across distributed systems.

How bearer tokens work in HTTP

A bearer token is sent in the HTTP Authorization header with the Bearer scheme:

GET /api/users/me HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

The server validates the token (looking it up in a database, decoding a JWT, or calling an introspection endpoint) and either honors the request or returns 401 Unauthorized. The complete flow:

1. Client authenticates. Via OAuth 2.0 (authorization code, client credentials, etc.), API key exchange, or login form.
2. Server issues a bearer token. Returned in the response, typically as JSON: {"access_token": "...", "token_type": "Bearer", "expires_in": 3600}.
3. Client stores the token. In memory, secure storage, or httpOnly cookie (for browser apps).
4. Client sends token with each request. In the Authorization header.
5. Server validates each request. Token signature/expiry/scope checks.
6. Token expires. Client uses a refresh token to get a new access token, or re-authenticates.

Bearer token formats

Opaque tokens

A random string with no embedded information. The server stores token-to-user mappings in a database and looks them up on each request.

Authorization: Bearer 7b3f2e8a-1c4d-4b6a-9e7f-2c8d3a4b5e1f

Pros: revocation is instant (delete from DB). Cons: every request requires a database lookup.

JWT (JSON Web Tokens)

A self-contained signed token format (RFC 7519). The payload contains the claims (user ID, scopes, expiry); the signature proves authenticity without server-side state.

Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWTs are three base64-encoded segments separated by dots: header.payload.signature. Pros: no database lookup needed for validation. Cons: revocation is harder (token is valid until expiry); larger payload than opaque tokens.

Reference tokens

A hybrid: short opaque token that maps to a server-side session containing claims. Used by some IdPs (IdentityServer) when JWT size is a concern but introspection is acceptable.

Bearer token vs other auth schemes

OAuth 2.0 and bearer tokens

OAuth 2.0 is the framework that standardized bearer tokens for API access. Common OAuth 2.0 flows that issue bearer tokens:

• Authorization Code (with PKCE). User-facing apps. Redirect to provider, user authorizes, app receives code, exchanges code for bearer token. PKCE adds protection for public clients (mobile, SPA).
• Client Credentials. Server-to-server. App authenticates with client_id + client_secret directly, gets a bearer token. No user involved.
• Refresh Token. Long-lived token used to get new short-lived access tokens. Separate from access tokens, with stricter storage requirements.
• Device Code. Devices without browsers (smart TVs, CLI tools). User authorizes on a separate device using a short code.

Security considerations

Because possession equals access, bearer tokens demand careful handling:

• HTTPS is mandatory. A bearer token sent over HTTP is one packet capture away from full account access. Never accept bearer tokens on plain HTTP.
• Short TTLs. Access tokens should expire quickly (15min - 1 hour typical). Use refresh tokens for longer sessions.
• Secure client storage. Browser SPAs: httpOnly secure cookie, not localStorage (XSS-vulnerable). Mobile: Keychain/Keystore. Server: env vars or secret manager.
• Token revocation. Implement an introspection or revocation endpoint. JWTs need a denylist + short TTL strategy since they can't be revoked instantly.
• Scope minimization. Issue tokens with the least scope needed. A token that can read profile data shouldn't be able to delete the account.
• Rotate refresh tokens. Issue a new refresh token each time one is used; detect reuse as a sign of compromise.
• Audience and issuer validation. Verify that JWTs were issued for your service (aud claim) by your trusted IdP (iss claim).

Common bearer token mistakes

• Storing tokens in localStorage in browser apps. XSS attacks read localStorage. Use httpOnly cookies.
• Logging tokens. Server logs, monitoring tools, or error trackers may capture Authorization headers. Filter them out.
• Long-lived access tokens. An access token that lives for 30 days defeats the security advantage over API keys.
• No refresh token rotation. Reuseable refresh tokens that don't rotate make detection of compromise impossible.
• Trusting JWT claims without signature verification. Anyone can craft a JWT with any claims; the signature is what proves authenticity.
• Using HS256 (symmetric) when RS256 (asymmetric) is appropriate. HS256 means anyone with the verification key can also issue tokens.

Testing bearer token APIs at scale

Load testing APIs that use bearer tokens has specific concerns:

• Token issuance is itself an API. If your load test starts by hitting /oauth/token 1,000 times, you're load-testing your auth server too. Consider pre-issuing tokens or mocking the auth server.
• Token expiry mid-test. A 30-minute load test with 15-minute token TTL means tokens expire mid-flight. Implement refresh logic in scripts.
• Per-user vs shared tokens. Load tests with one shared token miss per-user rate limiting. Issue per-VU tokens for realistic results.
• Test token revocation paths. Verify that revoked tokens return 401 within an acceptable window (especially important for JWT denylist implementations).

FAQ: Bearer tokens

Are bearer tokens secure?

Yes, when handled correctly: HTTPS only, short TTLs, secure client storage, scope minimization. The security depends on operational discipline more than the cryptography.

What's the difference between a bearer token and a JWT?

A bearer token is a category — anything sent in Authorization: Bearer header. A JWT is a specific format of bearer token with embedded claims and a signature. Most modern bearer tokens ARE JWTs, but bearer tokens can also be opaque (random strings).

How long should a bearer token last?

Access tokens: 15 minutes to 1 hour. Refresh tokens: hours to days, or session-bound. Long-lived tokens are convenient but increase blast radius if stolen.

Can I revoke a JWT bearer token?

Not natively — JWTs are valid until expiry. Revocation requires a denylist (revoked-token list checked on each request) or short TTL + refresh token rotation strategy. Some teams accept this trade-off; others use opaque tokens with introspection for instant revocation.

What happens if my bearer token is stolen?

The thief has full access until the token expires. This is why short TTLs matter. Implement token introspection logging to detect anomalous usage patterns (different IP, different user agent) and trigger refresh-token rotation alerts.

Can I use bearer tokens in browser apps?

Yes, but with care. Store in httpOnly secure cookies (not localStorage). The Authorization header pattern is harder in browsers because cookies are auto-sent; either send the cookie value as the bearer token in JS-fetched requests, or use cookie-based session auth (which has its own CSRF concerns).

Test bearer-token-protected APIs with LoadFocus

If you're load testing APIs that use bearer tokens, LoadFocus runs JMeter and k6 scripts from 25+ cloud regions with native support for OAuth flows, header management, and per-VU token rotation. Sign up for a free tier at loadfocus.com/signup — no credit card — and run your first authenticated API load test in under 5 minutes.