Cookies, sessions and tokens explained

Cookies, sessions and tokens are often discussed together because they all help a web application recognise a later request, but they are not the same thing. A cookie is a browser storage and transport mechanism, a session is server side continuity, and a token is a credential or claim container that can be sent with a request. Keeping the roles separate is the difference between a clean design and a confusing one.

HTTP is stateless

HTTP does not remember earlier requests by itself. Each request carries the information the server needs to understand it. State is added by application design, most commonly with cookies, server side sessions or bearer tokens.

That stateless base is useful because it keeps the protocol simple and cacheable. It also means authentication state must be handled deliberately.

What a cookie does

A cookie is small data set by a server with the Set-Cookie response header and returned by the browser in later Cookie request headers when the cookie rules match. The browser decides when to send it based on attributes such as Domain, Path, Secure, HttpOnly, SameSite, Expires and Max-Age.

Use Secure for cookies that should only be sent over HTTPS. Use HttpOnly so client side JavaScript cannot read the cookie through document.cookie. Use SameSite to control when the cookie is sent with cross-site requests.

A cookie is not automatically a session. It is just a mechanism for storing and sending name value data under browser controlled rules.

What a server side session does

A server side session stores state on the server. The browser usually receives an opaque session identifier in a cookie. On each request, the server looks up that identifier and recovers the associated session state.

This model gives the server direct control over revocation and expiry. It also keeps sensitive session data out of the browser. The trade-off is that the service must store session state or use infrastructure that can locate it reliably.

Regenerate the session identifier after authentication and privilege changes. That reduces the risk from session fixation, where an attacker tries to force a known session identifier onto a user before they log in.

What a token does

A token is a value presented by the client as proof of authentication, authorisation or both. It may be opaque, meaning only the issuer can interpret it. It may also be structured, such as a signed JSON Web Token.

Bearer tokens are common. Any party in possession of a bearer token can use it, so it must be protected as a secret. If a bearer token is stolen, the server cannot tell from the token alone that the wrong party is using it.

Tokens are often sent in the Authorization header with the Bearer scheme. They can also be stored in cookies, but doing so means the browser cookie rules, CSRF protections and same-site behaviour become part of the security design.

Cookies versus Authorization headers

Cookies are sent automatically by the browser when their rules match. This is convenient for web applications, but it means cross-site request forgery has to be considered for state changing requests.

Authorization headers are usually added by application code. This can reduce accidental cross-site submission, but it does not remove the need to protect the token from script access, logs, browser extensions and accidental exposure.

There is no universal winner. Choose based on the client type, threat model, revocation needs and deployment architecture.

Expiry and revocation

Short lifetimes reduce the value of a stolen credential. Server side sessions can usually be revoked immediately by deleting or invalidating server state. Opaque tokens can also be revoked if the server checks them against issuer side state.

Self-contained signed tokens are harder to revoke before expiry because the resource server may be able to validate them without contacting the issuer. That can be useful for scaling, but it pushes more importance onto short lifetimes, key rotation and careful audience and scope checks. Where logout must invalidate a self-contained token immediately, the usual answer is a server side denylist, which gives up some of the stateless benefit.

Storage choices matter

For browser based applications, HttpOnly Secure cookies are usually safer for long lived session credentials because JavaScript cannot read them. Local storage and session storage are accessible to any JavaScript running in the origin, so a single XSS bug can expose every token stored there.

This does not make cookies magic. A cookie based design still needs SameSite, CSRF defences for unsafe methods, secure transport, session rotation, logout and server side authorisation checks.

Practical defaults

Use HTTPS everywhere. Put session identifiers in Secure, HttpOnly cookies. Set SameSite to Lax unless the application has a confirmed cross-site requirement. Use SameSite=None only with Secure and only when cross-site cookie sending is required.

Keep identifiers unpredictable and generated by a cryptographically secure source. Do not put secrets, roles or personal data in unsigned client readable cookies. Do not treat token claims as trustworthy unless the token signature, issuer, audience, expiry and intended use have been validated.

Common mistakes

Do not store access tokens in local storage without understanding the XSS risk. Do not use long lived bearer tokens for browser sessions unless there is a strong reason. Do not rely on the presence of a cookie as authorisation. Authentication says who the caller is. Authorisation decides what that caller may do.

Do not log cookies, access tokens or refresh tokens. Logs often have broader access and longer retention than application memory.

Conclusion

Cookies transport browser state, sessions keep continuity and tokens carry credentials or claims. Secure designs keep these roles separate. The safest approach is usually boring: HTTPS, HttpOnly Secure cookies for browser sessions, short lifetimes, server side revocation where needed, CSRF protection and strict validation on every request.