How Authentication Evolved: From Cookies & Sessions to JWT in Distributed Systems

Login authentication is an unavoidable topic in any system; as system architecture evolves, authentication solutions adapt. Below we introduce the relationship among Cookie, Session, and JWT across architectural evolution.

1. Monolithic Architecture

In the monolithic stage, front‑end and back‑end code reside in a single project, so there is no cross‑origin issue. Authentication uses Cookie and Session. The process is as follows:

When a user accesses the server, the request carries the sessionId issued by the server; the back‑end retrieves the logged‑in user information using the sessionId.

2. Front‑end/Back‑end Separation

In a single‑project architecture, development and deployment become cumbersome, leading to a front‑end/back‑end separation model:

Front‑end/back‑end separation introduces cross‑origin problems, which block browser‑server data exchange and prevent obtaining the sessionId from Cookie. To continue using Cookie and Session, Cross‑Origin Resource Sharing (CORS) must be configured. The CORS flow is:

After solving cross‑origin with CORS, authentication still uses Cookie and Session.

3. Distributed Systems

As business grows, a single system is split into multiple subsystems deployed on many servers. Sessions are not shared across services, so using Cookie and Session requires session sharing.

The industry commonly adopts Single Sign‑On (SSO) to solve session sharing in distributed environments. The SSO flow is:

(1) The user requests the Order service; the service detects no login and redirects to the authentication center.

(2) The authentication center presents a login page; after verifying credentials, it writes the login state into the SSO session and sets an SSO Cookie in the browser.

(3) After SSO login, a ticket is generated and the browser redirects to the Order service with the ticket as a parameter. The Order service validates the ticket with the SSO backend, then writes the login state into its own session and sets a Cookie for its domain.

This achieves cross‑domain SSO, so subsequent accesses to the Order service find the user already logged in.

(4) When the user later accesses the Product service, the service redirects to SSO; because the user is already logged in via SSO, no additional login is required.

(5) SSO generates a ticket for the Product service; the browser redirects with the ticket, the Product service validates it with SSO, then writes the login state into its session and sets a Cookie for its domain.

Below is a design that uses Redis and Cookie to implement SSO:

4. Decentralized Authentication in Distributed Systems

Cookie/Session and Cookie/Redis mechanisms require the server to maintain a session component to identify logged‑in users. Stateless login, typically implemented with JWT, allows the server to determine the user directly from the request.

Stateless login’s biggest advantage is strong horizontal scalability, as servers do not need to store per‑user login data, making it easy to add instances to a cluster.

The main drawback is the inability to log out; once a token is issued it remains valid until it expires, so designs often add Redis to enable forced logout.

Summary

(1) Cookie and Session are the basic stateful authentication methods; as architectures evolve, they become insufficient, prompting new solutions to keep authentication functional.

(2) Because Cookie and Session are stateful, stateless mechanisms like JWT have emerged for specific scenarios.