How Cookies, Sessions, and Tokens Keep Web Users Logged In

Cookie

Cookies are a client‑side mechanism for storing small pieces of user information, typically limited to about 4 KB and saved in the browser. They allow the server to recognize returning users without requiring them to log in again for each page request.

Session

A session records client state on the server. It stores a SessionID (often sent to the client via a cookie) together with user data such as basic profile, permissions, organization info, and custom variables. The session data can be kept in memory, a database, or files, and is looked up on each request using the SessionID.

When a user logs in, the server creates a SessionID, returns it in a cookie, and the browser automatically includes that cookie on subsequent requests. The server then retrieves the corresponding session record to restore the user's context.

Sessions have a timeout; if a session remains inactive beyond this period, the server discards it to free memory.

Token

Because HTTP is stateless, each request must carry enough information for the server to identify the client. Tokens provide a lightweight alternative to sessions by embedding authentication data directly in a signed string.

A token is generated by the server using a unique user identifier, a timestamp, and a cryptographic signature (often a hash of the token payload plus a secret key). The token is Base64‑encoded and returned to the client, which stores it (e.g., in a cookie or local storage) and includes it in future requests.

When the server receives a request with a token, it validates the signature and timestamp, allowing stateless authentication without persisting user‑login records.

Client sends username and password to log in.

Server verifies credentials.

On success, server issues a token and returns it to the client.

Client stores the token (e.g., in a cookie or database).

For each subsequent request, the client includes the token.

Server validates the token; if valid, it processes the request and returns the data.

In mobile apps, the token is often a randomly generated 32‑character string stored on the device. The server also tracks token expiration; if the token is expired or missing, the client must re‑authenticate.

Example analogy: ordering a pancake with extra eggs. Each ingredient request adds a token‑like piece; the final pancake represents the assembled result. If the server restarts and loses token data, the client must log in again.