From Cookies to JWT: Mastering Web Session and SSO Strategies

First Chapter

Birth and Characteristics of Cookies

Web servers are stateless, meaning each request is independent and the server only knows what the client sends in the request. To track user state—such as a shopping‑cart history—cookies were introduced. The server sends a Set‑Cookie header; the browser stores the cookie and includes it in subsequent requests, allowing the server to recognize the request context.

Cookies represent the transition from stateless to stateful communication.

When a user logs in, the server generates a cookie, the browser saves it as a key‑value pair, and on the next request the cookie is sent back. The server validates the cookie; if it matches, the request is authenticated.

Cookies are stored in the browser at the locations shown below:

Key characteristics of cookies:

Stored on the client and can be tampered with; not secure.

Sent with every HTTP request, affecting performance; size limited to 4 KB.

A single browser can store up to 20 cookies per domain and about 300 cookies total.

Mobile browsers have limited cookie support.

Cookies store plain text; objects must be serialized, and deserialization is required on read.

Cookie Sharing Between Sub‑domains

Consider two sub‑domains http://a.xxx.com and http://b.xxx.com. By default, a cookie set by domain A is only sent to A (host‑only cookie). To share it, the server can set the cookie’s Domain attribute to the common parent domain, e.g., xxx.com, and set Path=/. RFC 6265 ignores leading dots, so both xxx.com and .xxx.com are valid. This principle underlies Single Sign‑On (SSO).

For deeper sub‑domains such as a.b.e.f.com.cn and c.d.e.f.com.cn, the shared domain can be .e.f.com.cn or .f.com.cn. Browsers reject a cookie with domain .com.cn to prevent abuse.

When both domains set a cookie with the same name under the same shared domain, the later one overwrites the previous value, illustrating that cookie names must be unique within a domain.

Properly setting Domain and Path reduces unnecessary data transmission and saves bandwidth.

Cookie‑Session Model

Because cookies are limited in size and quantity, large user state is stored on the server. The server generates a sessionId, stores the session data in a fast cache (e.g., Redis or Memcached), and sends the sessionId to the client via a cookie. Subsequent requests include the sessionId, allowing the server to retrieve the user’s state without exposing it to the client.

Storing sessions directly on the web server is costly and does not work well with load‑balanced environments. A dedicated cache server acts as a shared session store, enabling any web node to access the same session data.

Cookie‑Session Workflow Diagram

This architecture introduces a single point of failure: if the session store goes down, authentication fails. In practice, the session store is deployed as a clustered service with load balancing to improve reliability.

Considerations:

If the server restarts, in‑memory session data is lost unless persisted.

Cache clusters periodically flush data to disk for durability; a total outage would still cause data loss for the interval between flushes.

Limitations of the Cookie‑Session Approach

Relies on cookies; users can disable them.

Not suitable for cross‑platform (e.g., mobile app) scenarios.

Frequent cache lookups increase memory usage and server load.

Stateful servers make horizontal scaling difficult without a shared session store.

Potential single‑point‑of‑failure for SSO.

Second Chapter

Three Types of Single Sign‑On (SSO)

SSO allows a user to log in once and access multiple trusted applications. The three scenarios are:

Within the same site.

Across systems sharing the same top‑level domain.

Across systems with different top‑level domains.

When domains differ, cookies cannot be shared directly, requiring alternative mechanisms.

Central Authentication Service (CAS) Principle

CAS provides a dedicated authentication server. The flow mirrors the cookie‑session model but adds an SSO layer:

User accesses system A and is redirected to the CAS server for login.

CAS validates credentials, creates a session, and issues a session cookie and a Service Ticket (ST).

The browser sends the ST to system A; system A validates the ST with CAS and establishes its own session cookie.

When the user later accesses system B, CAS detects the existing login, issues a new ST, and system B validates it similarly, achieving seamless login without re‑entering credentials.

The redirection and ticket exchange are conceptually similar to OAuth 2.0 flows.

Third Chapter

To avoid the drawbacks of a centralized session store, a decentralized approach encrypts all session data into the token itself, eliminating the need for server‑side storage.

JSON Web Token (JWT) Model

After a successful login, the server issues a signed token containing user information. The client includes this token in subsequent HTTP requests (e.g., via the Authorization header). The server verifies the signature using a secret key; if valid, the token’s payload is trusted and can be used for authorization without consulting a session store.

Advantages include stateless servers, easier horizontal scaling, and cross‑platform compatibility. However, token revocation is limited to expiration, and token size can increase bandwidth usage.

JWT Workflow Diagram

Pros and Cons of JWT

Drawbacks

Logout is merely client‑side token removal; a stolen token remains valid until expiration.

Security hinges on the secrecy of the signing key.

Signed payloads are longer, consuming more bandwidth.

Benefits

Independent of cookies; works across browsers, mobile apps, and other clients.

Highly scalable; no central session store required.

Preserves server statelessness.

Reduces repeated validation calls to a central SSO service.