What is an authentication token and how do you protect one?

An authentication token is a short credential a system issues after you sign in, which your client then presents on later requests instead of sending the password again. Whoever holds a bearer token can use it, so protecting tokens in storage and in transit matters as much as protecting passwords.

Why do tokens exist?

Sending a password with every request would expose it constantly. So a server verifies the password once, then hands back a token that stands for that successful login. Browsers usually carry it as a session identifier in a cookie. APIs often carry it in a header.

What does "bearer" mean?

RFC 6750 describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Its key sentence is that any party in possession of a bearer token can use it to get access to the associated resources, without demonstrating possession of a cryptographic key. To prevent misuse, the RFC says bearer tokens need to be protected from disclosure in storage and in transport.

That is the whole risk model in two lines. A copied token works from any machine until it expires or is revoked, with no password, and no second factor, because those happened earlier.

Is a JWT the same thing?

Not quite. A JSON Web Token, defined in RFC 7519, is a compact, URL-safe way of representing claims between two parties. The claims are a JSON object that is the payload of a signed structure or the plaintext of an encrypted one, so they can be digitally signed or integrity protected. A JWT is a format. It can be used as a bearer token, and then it carries the same theft risk, with an added property: a self contained token can often be validated without a database lookup, which makes instant revocation harder unless you design for it.

A signed token is not necessarily a secret one. Unless it is also encrypted, assume anyone who holds it can read the claims.

What do session identifiers need?

The OWASP Session Management Cheat Sheet gives concrete rules for the cookie case. Session identifiers must have at least 64 bits of entropy to resist brute force guessing, generated with a cryptographically secure random number generator. The HttpOnly cookie attribute tells browsers not to let scripts read the cookie through the DOM, which OWASP calls mandatory to prevent session ID theft through cross site scripting. The Secure attribute keeps the cookie from being sent over unencrypted connections.

A constructed example

A team stores its API token in a browser's local storage so a single page app can call the backend. A cross site scripting flaw in a third party widget lets injected script read local storage and send the token to an attacker, who then calls the API as the user for the next twelve hours. Moving the session to an HttpOnly, Secure cookie, shortening token lifetime to fifteen minutes with a refresh step, and fixing the widget would each have changed that outcome.

How to check or apply this

1. Inventory the token types you issue: session cookies, API keys, OAuth access tokens, refresh tokens.
2. Give each a short lifetime and a revocation path. Test that revocation works.
3. Send tokens only over TLS.
4. For cookies, set HttpOnly and Secure and generate identifiers from a secure random source with at least 64 bits of entropy.
5. Keep tokens out of URLs, logs and error messages. Search your logs for them.
6. Scope tokens to the least privilege needed, so a stolen one does less.
7. For JWTs, verify the signature and the expected algorithm, issuer, audience and expiry on every request.
8. Rotate and scan for tokens committed to code. A token in a repository is public the day the repository is.

Quick check

Sources

• RFC 6750: The OAuth 2.0 Authorization Framework, Bearer Token Usage
• RFC 7519: JSON Web Token (JWT)
• OWASP Session Management Cheat Sheet

Last reviewed: 18 October 2026.