Sessions & Tokens

You verify a password once. The user then makes four hundred requests, and HTTP remembers nothing at all between them — every request arrives as if the login never happened. Something has to travel with each one to say "this is still that person", and whatever you choose becomes the thing an attacker steals, because stealing it is equivalent to knowing the password and considerably easier. This track is about choosing that carrier deliberately and defending it.

The first option is a session id in a cookie: a meaningless random value that indexes state on your server. Its flags are not decoration. httpOnly keeps JavaScript from reading it, which is what turns a cross-site scripting bug from total account compromise into something less severe. Secure keeps it off plain HTTP. SameSite governs whether it rides along on requests triggered by other sites, which is the crux of cross-site request forgery — where a page you visited quietly makes an authenticated request to a site you were already logged into, and your browser helpfully attaches the cookie. You will see why CSRF and XSS need different defences, and why fixing one does nothing for the other.

The second option is a self-contained token: the claims travel in the token itself, signed, so any server can verify it without shared state. That scales across services beautifully and creates the problem this track wants you to face squarely — revocation. A session id can be deleted server-side and is instantly dead. A signed token is valid until it expires, whoever holds it, which means logout becomes a polite suggestion unless you add back some of the state you removed. Short lifetimes with refresh, or a revocation list, are the usual answers, and both are compromises. Making that trade-off explicitly is the point of the track; the JWT verification mechanics come next in P55.