Understanding Cookies, Sessions, and JWT Tokens: Comparison, Advantages, and Pitfalls

Cookie

Cookies originated in the early web to maintain state between stateless HTTP requests, storing small text data on the client to identify users and track sessions such as shopping carts.

Each request returns a cookie containing the product IDs, which quickly grows in size as the cart expands, creating unnecessary bandwidth overhead.

Session

Sessions move the state to the server: the client only stores a sessionId in a cookie, while the server keeps the full shopping‑cart data, dramatically reducing request size.

When multiple servers are used, three common solutions address the loss of session affinity:

Session replication – copy the session to every node (causes data redundancy and performance cost).

Session sticky – bind a client to a specific server using Nginx ip_hash (fails if the chosen server goes down).

Session sharing – store sessions in a central store like Redis or Memcached (adds a network hop but scales well).

Token: No‑Session Authentication

JWT tokens allow the server to issue a signed token containing the user ID; the client stores the token (typically in local storage) and sends it in the Authorization header on each request.

A JWT consists of three Base64‑encoded parts:

Header – specifies the signing algorithm.

Payload – carries non‑sensitive claims such as userId and expiration.

Signature – generated by the server using a secret key to ensure integrity.

When a request arrives, the server recomputes the signature from the header and payload and compares it to the token’s signature; if they match, the token is valid and the userId can be read directly from the payload, eliminating the need for a Redis lookup.

Advantages of Tokens

No server‑side storage required, simplifying horizontal scaling.

Works across domains and mobile platforms because the token is sent in headers, not cookies.

Drawbacks of Tokens

Tokens are long (header + payload + signature), potentially exceeding cookie size limits and adding bandwidth overhead.

Storing tokens in local storage makes them accessible to JavaScript, raising XSS concerns; they cannot be revoked server‑side without a blacklist, which re‑introduces server state.

Cookie vs. Token Security

Cookies are vulnerable to CSRF because browsers automatically attach them to same‑origin requests. Tokens avoid CSRF but, when stored in local storage, are exposed to XSS attacks. Proper CSRF protection still requires anti‑CSRF tokens.

Example of a CSRF attack using an image tag:

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">

Both mechanisms need HTTPS to protect data in transit.

Summary

Cookies, sessions, and JWT tokens are all methods for authenticating users; sessions keep state on the server, while tokens embed state in a signed payload. Choose sessions for most traditional web apps, and tokens for single‑sign‑on, mobile, or stateless micro‑service scenarios.