Classic Authentication

What Is Classic Authentication?

At its core, authentication means verifying who a user is.

In the classic web era (early 2000s-2010s), websites were monolithic – both the frontend and backend ran on the same server.

It refers to the traditional, credential-based method of verifying a user's identity – usually by asking for:

• Username / Email / User ID
• Password

A typical login process looked like this:

1. The user enters a username and password on a login page.
2. The server checks the credentials in the database.
3. If valid, the server creates a session and assigns a session ID.
4. The session ID is stored in the browser as a cookie.
5. On every subsequent request, the browser sends that cookie back.
6. The server reads the session ID, finds the session data in memory or a database, and identifies the user.

This was stateful authentication – because the server maintained the "state" of who was logged in.

 Where the Session Lived

The server stored the session data somewhere – typically in:

• In-memory storage (like a hash map) for small apps.
• Database or file storage for persistence.
• Later, Redis, or Memcached for better performance.

Each session stored things like:

{
  "user_id": 101,
  "name": "Alice",
  "role": "admin",
  "created_at": "2025-10-29T12:00:00"
}

When the user made any API or page request, the session ID from the cookie pointed back to this object.

The High-Level Flow

Let's beak down what happens step-by-step when a user logs in using classic authentication.

Step 1: User Submits Credentials

The user fills in a login form and submits:

username: alice
password: secret123

These credentials are sent to the server – typically via an HTTP POST request (e.g., /login).

Step 2: Server Receives and Validates Input

The server receives the request and:

1. Looks up the user record in the database by username or email.
2. Retrieves the stored password hash for that user.
3. Compares the received password (after hashing) with the stored hash.

Step 3: Password Verification (Hashing)

Passwords are never stored in plain text.

Instead, during registration, the system stores something like this:

username: alice
password_hash: $2a$10$Vh9xEJ1M./rOjgEupPlO6eWAcxchbA6t8iGZfCkDq... (bcrypt hash)
salt: (may be embedded)

During login:

1. The user's entered password (secret123) is passed through the same hashing function (e.g., bcrypt, PKDF2, Argon2) using the same salt.
2. The resulting hash is compared with the stored hash.
3. If they match -> authentication succeeds.

Step 4: Session Creation

Once credentials are verified, the server creates a session for the user.

Two main models exists:

A. Server-Side Sessions (Classic Web Model)

• The server creates a session ID (a random unique string).
• The session data (e.g., user ID, role, last login) is stored in a server-side store (like Redis or in-memory).
• The session ID is sent to the client as a cookie.

Example cookie:

Set-Cookie: session_id=abc123xyz; HttpOnly; Secure

Now, each subsequent request from the user includes this cookie, allowing the server to know who is making the request.

B. Client-Side Tokens (Modern Approach)

Not classic, but worth noting – modern systems use JWTs (JSON Web Tokens) stored client-side.

However, in classic authentication, the session ID and session data stays on the server.

Step 5: Session Validation

For each new request:

1. The browser sends the session_id cookie.
2. The server looks up the session in its store.
3. If found and valid, the user is considered authenticated.
4. The session may include additional data like:
   1. User ID
   2. Permissions / roles
   3. CSRF token

Step 6: Session Expiry / Logout

Sessions don't last forever. There are two main termination methods:

• Timeout: Session expires after a fixed period of inactivity (e.g., 30 minutes).
• Manual Logout: The user clicks “Logout” -> the server invalidates the session record, removing it from memory or the database.

The Challenges – Why It Broke at Scale

As systems evolved, the classic pattern started showing cracks:

1 Statefulness

• Each user session lived in memory or storage on one specific server.
• In a distributed environment, different servers couldn't share session state easily.
• You needed session replication or sticky session, both hard to scale.

2 Scalability

• When millions of users logged in, session storage became huge.
• Memory-heavy session stores slowed down the system.
• Horizontal scaling became painful – load balancers had to “pin” users to specific servers.

3 Security

• Session IDs had to be unguessable.
• If cookies weren't marked HttpOnly and Secure, they could be stolen.
• Session fixation and CSRF were common attacks.

4 API Incompatibility

• Mobile apps and APIs needed stateless authentication, but classic sessions were tied to browser cookies.

As web systems grew distributed and API-driven, the classic model couldn't keep up.

The world needed something that could scale horizontally, work across services, and stay stateless.