🍪 Cookies, Sessions and Authentication

Cookies, Sessions and Authentication

HTTP has no memory. Every request arrives as if the server had never met you, which means "being logged in" has to be reconstructed from something the browser sends with each request. That something is almost always a cookie, and a session cookie is a bearer credential: whoever holds it is the user, no further questions asked. Nearly every rule in this module follows from that one sentence.

What a session actually is

On successful authentication the server generates a session identifier — an opaque, unpredictable value from a cryptographically secure random source, 128 bits of entropy or more — and stores the real state (user id, roles, issue time, MFA status) server-side under that key. The identifier travels to the browser in a Set-Cookie header and comes back in a Cookie header on every request matching the cookie's scope. It should mean nothing on its own: if it decodes to user=42|role=admin, you have handed the client your authorisation state.

HTTP/1.1 200 OK
Set-Cookie: __Host-sid=Zk8x3Qv1r7Np2Lm9Td5Hb0Yc; Path=/; Secure; HttpOnly;
            SameSite=Lax; Max-Age=1800

GET /account HTTP/1.1
Cookie: __Host-sid=Zk8x3Qv1r7Np2Lm9Td5Hb0Yc

Cookie attributes in full

Lax by default. Chromium-based browsers treat a cookie with no SameSite attribute as Lax, plus a compatibility exception that lets a top-level cross-site POST carry a cookie for roughly the first two minutes of that cookie's life. Not every browser has adopted identical defaults. So: never rely on the default or on the exception — set SameSite explicitly on every cookie you issue, and keep real CSRF tokens on state-changing endpoints regardless.

The __Host- and __Secure- prefixes are not naming conventions — browsers enforce them by refusing to store a Set-Cookie that violates the rules:

• __Secure- requires the Secure attribute and that the cookie was set from a secure origin.
• __Host- requires Secure, requires Path=/, and requires that no Domain attribute is present, making the cookie host-only.

That third condition is the valuable one: a host-only cookie cannot be written by a sibling subdomain or by a network attacker on a related HTTP host, which shuts down cookie tossing and session fixation via subdomain. If you take one concrete action from this module, name your session cookie __Host-something. (SameSite and the prefixes are specified in the ongoing revision of RFC 6265 and are already implemented across mainstream browsers.)

Session fixation, and why you rotate on privilege change

The attack: the attacker makes the victim's browser hold a session identifier the attacker already knows — historically through a session id accepted in a URL parameter, today more often a cookie set from a subdomain the attacker controls. The victim then logs in. If the server keeps that identifier and simply attaches authenticated state to it, the attacker's copy is now an authenticated session.

// On successful authentication, in PHP
session_regenerate_id(true);   // new id, and destroy the old server-side record
$_SESSION['uid'] = $user->id;

Rotate on every change of privilege level, not only at login: after step-up MFA, after assuming an elevated role, after a password change. Never accept a session identifier from a URL or request body — cookie only. On logout, delete the server-side record; clearing the cookie alone leaves a valid credential in whatever log or cache captured it. Enforce an idle timeout and an absolute lifetime, keep a server-side list of active sessions per user so "sign out everywhere" is possible, and invalidate all other sessions on password change. Binding a session to a client IP or User-Agent sounds attractive and is mostly a support burden — mobile addresses change constantly — so treat a mismatch as a prompt to re-authenticate, not a hard kill.

JSON Web Tokens

A JWT (RFC 7519, signed using the JWS structure of RFC 7515) is three base64url segments separated by dots: header, payload, signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0IiwiZXhwIjoxNzAwMDAzNjAwfQ.<sig>

header  {"alg":"HS256","typ":"JWT"}
payload {"sub":"1234","exp":1700003600}

Both segments decode to exactly the JSON shown. That is a deliberately minimal payload; a production token normally carries more registered claims — iss (issuer), aud (audience), iat (issued at) and jti (a unique token identifier) — every one of which the verifier is expected to check rather than merely read.

base64url is encoding, not encryption: the payload is readable by anyone holding the token. Never put anything confidential in it.

The pitfalls, in order of how often they appear:

• alg: none — the JWS specification defines an "unsecured" mode with an empty signature. A verifier that reads the algorithm out of the attacker-supplied header and honours none accepts forged tokens outright.
• Algorithm confusion — a service that verifies RS256 using a public key, but lets the token choose the algorithm, can be given a token signed with HS256 using that public key as the HMAC secret. The key is public, so anyone can mint tokens. The fix for both: the verifier specifies the expected algorithm and key. The token never gets a vote.
• Weak HMAC secrets — an HS256 token is an offline cracking target. Use a long random key, not a memorable string.
• Header-driven key lookup — kid used unvalidated as a filename or SQL value is a traversal/injection sink; jku and x5u pointing at an attacker-hosted key set are worse. Resolve keys from a fixed, trusted configuration.
• Unvalidated claims — always check exp, and where present nbf, iss and aud. Skipping aud lets a token minted for one service be replayed against another that trusts the same issuer.

"Stateless" is the real trade-off. A signed token is valid until it expires, wherever it is presented. There is no server-side record to delete, so logging a user out, banning an account or revoking a role has no effect until expiry. Every practical answer reintroduces state: short access-token lifetimes (minutes) plus refresh tokens, a revocation list keyed on the jti claim, or a per-user "tokens issued before timestamp X are invalid" epoch checked on each request. At which point, ask what statelessness bought you.

JWTs fit short-lived service-to-service authorisation, API access tokens issued by an authorisation server, and any case where the verifier cannot reach the issuer's database. They fit poorly as a drop-in replacement for a browser session in an ordinary application: a random opaque identifier in a __Host- cookie is smaller, instantly revocable, and readable by nobody. Storing a JWT in localStorage so client-side code can read it also gives up HttpOnly, making XSS equal token theft. decode a token and read its claims → · sign and verify one →

OAuth 2.0 and OpenID Connect, conceptually

OAuth 2.0 (RFC 6749) is a delegated authorisation framework: an application obtains a token to act on a user's behalf against some API, without ever seeing the user's password. It is not an authentication protocol — "log in with X" is OpenID Connect, a thin identity layer on top that adds an ID token (a JWT describing the authentication event) and a userinfo endpoint. Four roles: resource owner (the user), client (your app), authorisation server (issues tokens), resource server (accepts them).

The current recommendation for essentially every client type is the authorisation code flow with PKCE (Proof Key for Code Exchange, RFC 7636):

1. client: code_verifier   = 43-128 random URL-safe characters (kept locally)
           code_challenge  = BASE64URL( SHA-256( code_verifier ) )
2. browser → authorisation server:
     ...&response_type=code&code_challenge=<challenge>
        &code_challenge_method=S256&state=<random>&redirect_uri=<exact>
3. authorisation server → browser → client:  ?code=<auth code>&state=<echo>
4. client → authorisation server (back channel):
     grant_type=authorization_code&code=<auth code>&code_verifier=<verifier>
5. server checks SHA-256(verifier) == stored challenge, returns tokens

PKCE binds the authorisation code to the client instance that started the flow, so a code intercepted at the redirect — via an open redirect, a hijacked custom URI scheme on mobile, or a logged referrer — cannot be exchanged by anyone else. state is a separate control protecting the callback against CSRF, and in OIDC the nonce parameter binds the ID token to your request so it cannot be replayed.

The implicit flow (response_type=token) returned an access token directly in the URL fragment. Current IETF security guidance deprecates it: tokens in URLs end up in browser history, Referer headers and server logs, and the flow cannot authenticate the client at the token step. The resource-owner password credentials grant, where the app collects the password itself, is deprecated for the obvious reason. Register exact-match redirect URIs, never wildcards.

Password storage

If a database is stolen, the only thing between the attacker and every user's password is how expensive each guess is. General-purpose hashes are the wrong tool precisely because they are fast: MD5, SHA-1 and the SHA-2 family are built to be computed billions of times per second on commodity GPUs. You want a password hashing function with deliberately tunable cost, ideally memory-hard so custom hardware gains less advantage.

// PHP: the algorithm, salt and parameters are encoded in the stored string
$hash = password_hash($password, PASSWORD_ARGON2ID);
// $argon2id$v=19$m=65536,t=4,p=1$<salt>$<hash>

if (password_verify($password, $hash)) {
    if (password_needs_rehash($hash, PASSWORD_ARGON2ID)) {
        $hash = password_hash($password, PASSWORD_ARGON2ID);  // upgrade cost silently
    }
}

Salts are per-user random values, at least 16 bytes, stored alongside the hash — the functions above generate and embed them for you. They are not secret. Their job is to defeat precomputation (rainbow tables) and to stop two users with the same password producing the same hash. A single global salt does neither.

Peppers are a secret key held outside the database — environment variable, key manager, HSM. Apply it as an HMAC over the password before the KDF, or encrypt the resulting hash with it. The payoff is real: a SQL-injection dump with no filesystem or KMS access yields hashes that cannot be attacked at all. The cost is awkward rotation, so version your peppers and store the version with each hash. Finally, screen new passwords against known-breached corpora and follow NIST SP 800-63B — favour length, permit long passphrases and pasting, drop mandatory composition rules and scheduled expiry. analyse a password's strength → · check one against breach data via k-anonymity → · generate a strong one →

Multi-factor authentication

The differentiator is not "how many factors" — it is whether the second factor can be relayed by a machine-in-the-middle phishing proxy. Adversary-in-the-middle kits defeat SMS, TOTP and push by design, because in each the user hands over a value the proxy replays immediately. WebAuthn breaks that: the signature is bound to the origin the browser is actually talking to, and the user has nothing to type. Where legacy factors must remain, alert on unusual authentications and treat recovery codes as credentials — they are stored, static, and bypass everything above.

TOTP is still a reasonable second factor and is easy to implement correctly: store the shared secret encrypted, allow a small clock-drift window (typically one step either side), reject a code already used within its window, and rate limit verification — six digits is a million possibilities, which is not many when guessing is free. generate and verify TOTP codes →

Account recovery: the usual weakest link

Recovery is the flow that exists to bypass authentication, so it inherits the security of the weakest thing it trusts. An account protected by a hardware key and a 20-character passphrase, recoverable by answering "mother's maiden name", is protected by the maiden name. Rules that hold up:

• Reset tokens are high-entropy, single-use, and short-lived — 15 to 60 minutes is typical. Store a hash of the token, not the token.
• Invalidate the token on use, on a new reset request, and on any password change.
• Respond identically whether or not the address exists, or you have built an account-enumeration oracle.
• After a successful reset, rotate the session and invalidate every other active session, then notify the user out of band.
• If MFA is enrolled, require it during recovery — or, where that is impossible, impose a delay with notification so the legitimate owner can intervene.
• Retire knowledge-based questions entirely. The answers are public records, guessable, or reused across sites.