Tokens, Cookies, and Sessions

The easiest way to get confused about web authentication is to treat token, cookie, and session as competing products. They are not. They describe different parts of the identity flow.

A cookie is a browser storage and transport mechanism. A session is server-side state that remembers a logged-in user. A token is a credential the client presents to prove something about identity or permissions. These pieces can be combined in different ways. For example, a browser might store a session ID in a cookie, or it might store an access token in a cookie.

Start with the core flow

Authentication answers who are you? Authorisation answers what are you allowed to do?

A typical login flow is simple:

1. the user proves identity with a password, passkey, or external identity provider
2. the server issues some credential
3. the client sends that credential on later requests
4. the server validates it and applies permission checks

Most design choices come from where the state lives and how easy it is to revoke, rotate, and protect that credential.

Cookie: delivery, not identity

Cookies are name-value pairs that browsers attach to matching requests. On their own they say nothing about authentication. They are just a transport and storage mechanism.

What makes them useful for auth is that they support security attributes:

• HttpOnly reduces exposure to JavaScript and some XSS theft paths
• Secure ensures the cookie is sent only over HTTPS
• SameSite limits cross-site sending behaviour and helps reduce CSRF risk
• path, domain, and expiry control where the cookie applies

A cookie can hold a session identifier, a refresh token, or another small piece of identity state. The important question is what the server expects to find there.

Session: server-side login state

With session-based authentication, the server stores login state in a session store such as memory, Redis, or a database. The browser usually keeps only an opaque session ID in a cookie.

This has practical benefits. Revocation is straightforward because the server can delete the session. The browser does not carry sensitive user claims directly. The server can also change session contents without reissuing client-held credentials.

The trade-off is operational. Session stores must scale, expire correctly, and be shared across application nodes unless routing is sticky. Session-based auth is often an excellent choice for browser-first systems because it keeps control centralised.

Token: a client-presented credential

A token is any credential the client sends so the server can verify identity or permissions. It does not have to be a JWT, and it does not have to be encrypted.

Many access tokens are opaque random strings. The server looks them up in a datastore or introspection service. That gives strong revocation control, but it adds a lookup on each validation path.

Other tokens are self-contained and signed. In that model the server can validate the token locally and trust the claims inside it until expiry. That works well across many services, but revocation becomes harder. Once a signed token is issued, every service that accepts it may continue to trust it until it expires unless there is another revocation channel.

JWT, SSO, and OAuth 2.0

JWT means JSON Web Token. It is a token format for carrying claims such as user ID, issuer, audience, and expiry. Most JWTs are signed, not encrypted. The signature proves origin and integrity. It does not make the payload secret.

SSO means a user authenticates once and can then access multiple applications that trust the same identity provider. OAuth 2.0 is an authorisation framework for delegated access. OpenID Connect is the identity layer commonly added on top.

The practical design choice is not session versus token in the abstract. It is whether the system needs browser-centric simplicity, cross-service portability, fine-grained revocation, or delegated access to another platform. Good authentication design starts by being precise about those needs and honest about the attack surface they create.