HTTP is stateless — the server forgets you the instant a request finishes, so every authentication scheme exists to re-prove identity on each new request.

A web server handles thousands of independent requests. By design, HTTP keeps no memory between them: two requests from the same browser look, to the server, like requests from two strangers.

That statelessness is a feature for performance — requests are independent and can be answered in parallel, very fast. But it means there is no built-in concept of "being logged in." Every approach to web auth is really an answer to one question:

How does the client re-prove, on every single request, that it already authenticated earlier?

The three mechanisms in this topic are three different answers:

Tip: Hold onto the phrase "stateless HTTP" — it's the root cause that every card here circles back to.

Go deeper:

• MDN: HTTP overview — "HTTP is stateless" — MDN's statement of the statelessness that forces every re-proof scheme.
• OAuth 2.0 and OpenID Connect (in plain English) — frames web-auth as answers to "how do I re-prove identity each request".

The server keeps the real session data locally and hands the browser a small cookie holding only a Session Identifier (SID); the browser returns that SID on every request so the server can look the session back up.

This split is the whole idea of cookie-based (server-side session) authentication:

• Server side: after login the server stores the session — username, roles, expiry, etc. — in a text file, in-memory store, or database. The storage mechanism doesn't matter.
• Client side: the server sends back a cookie containing just the SID (a random, hard-to-guess string). The cookie is not the credentials themselves — it's a claim-ticket that points at the server-side session.

So the heavy state lives on the server; the cookie is just the pointer. That's why it's literally named cookie-based authentication.

Tip: Think of a coat check: you hand over your coat (session data stays with the server) and get a numbered ticket (the SID cookie). The number is useless to a thief who can't match it to a coat — which is why SIDs must be long and random.

Go deeper:

• OWASP Session Management Cheat Sheet — how to generate, store, and expire session IDs safely (the security side of the coat-check ticket).
• MDN: Using HTTP cookies — Set-Cookie/Cookie mechanics and the scope/security attributes that protect the SID.