Cookie-Based Session Authentication

The Problem With Basic & Digest Auth

Before cookies existed, browser had no good way to remember who you are between page requests.

Every request was isolated – the server couldn't tell that:

• The same person who loaded /login
• Is now requesting /dashboard

That's a huge problem, because HTTP is stateless – meaning every request is independent.

So the question became:

“How can we make a stateless protocol like HTTP remember users?”

The Solution – Sessions + Cookies

The answer: store login info on the server, and give the browser a session ID (like a claim ticket).

The big idea:

• The server keeps track of “who's logged in.”
• The browser just keeps a “session ID” cookie that points to that record.

So instead of sending passwords on every request, you just send the session ID.

How Cookie-Based Session Auth Works

Let's go through the complete flow

Step 1: The user logs in

User fills a form:

POST /login
username=alice&password=secret

Step 2: The server verifies credentials

If correct:

1. Creates a record in a session store:

   session_id: "abc123"
   user_id: 42
   expires: "2025-11-13T20:00:00Z"

2. Returns a Set-Cookie header:

   Set-Cookie: session_id=abc123; HttpOnly; Secure; Path=/

Step 3: The browser stores the cookie

The browser automatically saves the cookie session_id=123 for that domain

Step 4: The user makes another request

When the user visits /profile, the browser automatically includes the cookie:

GET /profile
Cookie: session_id=abc123

Step 5: The server checks the session

Server looks up abc123 in its session store:

• If found -> user authenticated
• If expired or missing -> force re-login

Step 6: Logout

When user clicks “logout”

• Server deletes the session entry
• Browser cookie expires
• Next request -> treated as unauthenticated

Example Session Store (Server-Side

This table is usually stored in:

• Memory (like Redis)
• Database
• Filesystem