How do cookies turn stateless HTTP into a "stateful" logged-in experience?

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.