Cookie vs Session vs JWT: Choosing the Right Authentication Strategy

Last week our team adopted JWT (JSON Web Token) for stateless user authentication and found many online articles inaccurate, so we compare Cookie, Session, and Token (JWT) to clarify their differences.

Cookie

Cookies originated in 1991 to maintain state for interactive web features like shopping carts, storing small text files on the client to identify users.

Cookies (or Cookies) are small text files stored on the client to track sessions, often encrypted.

When a user adds an item to a cart, the server stores the item ID in a cookie, which the browser sends back on subsequent requests, causing the cookie size to grow with the cart.

Because the cart data grows, each request carries unnecessary history, leading to inefficiency.

Session

Sessions store user data on the server; the cookie only carries a sessionId that identifies the user, reducing cookie size.

After login, the server creates a session, assigns a unique sessionId, and sends it to the browser via a cookie.

Subsequent requests include only sessionId; the server retrieves the user’s cart using this ID.

This eliminates the need to send all cart items in the cookie.

Cookie resides on the client, while session data resides on the server; sessionId relies on the cookie for transmission.

Session Pain Points

In a load‑balanced environment with multiple servers, a session created on one server may be unavailable on another, causing login failures.

Three common solutions:

1. Session replication – copy the session to all servers (adds redundancy and overhead).

2. Session sticky – route a client’s requests to the same server using Nginx’s ip_hash or similar.

upstream tomcats {
    ip_hash;
    server 10.1.1.107:88;
    server 10.1.1.132:80;
}

3. Session sharing – store sessions in a central store like Redis or Memcached.

Sharing adds a network hop but scales well with clusters.

Token: No Session!

Tokens avoid server‑side storage by embedding user ID and expiration in the token itself, signed by the server.

When a client sends a request, it includes the token in the Authorization header.

Answer: the server validates the token’s signature.

Answer: the token itself carries the uid.

The JWT consists of three parts: header (algorithm), payload (claims like uid and expiry), and signature (generated with the server’s secret).

Upon receiving a token, the server recomputes the signature and compares it; if they match, the token is valid and the uid can be read directly from the payload, avoiding a Redis lookup.

Note: header and payload are Base64‑encoded.

Tokens are stateless, but cannot be revoked individually unless a blacklist is maintained, which re‑introduces server storage.

Tokens are usually sent in the Authorization header, not cookies, to avoid cross‑origin cookie sharing issues.

Cookie vs Token Summary

Cookie limitations:

Cannot be shared across domains, making SSO difficult.

Tokens simplify SSO by placing the token in the Authorization header.

Mobile apps lack cookies, so token‑based authentication works naturally.

Token drawbacks:

1. Tokens are long, potentially exceeding cookie size limits.

2. Storing tokens in local storage exposes them to XSS attacks, and they cannot be invalidated before expiry without a server‑side blacklist.

Thus tokens suit short‑lived, one‑time commands.

Misconception: Cookies Are Less Secure Than Tokens

CSRF attacks exploit browsers automatically sending cookies with same‑origin requests, leading some to deem cookies insecure.

Tokens avoid CSRF because they are not sent automatically, but storing them in local storage makes them vulnerable to XSS.

Both storage methods have risks; transmission security relies on HTTPS.

Conclusion

Session and token are both authentication mechanisms; sessions store state on the server, tokens store state in the client and verify via signatures. Choose sessions for most cases, but prefer tokens for SSO or stateless, short‑lived operations.

References:

Cookie Session cross‑site sharing issues (SSO): https://blog.csdn.net/wtopps/article/details/75040224

Why not use JWT for sessions: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/