Across the HTTPS, CSRF, and XSS courses, one phrase kept recurring: "the session," "the credential," "riding the user's authority." This course is the foundation underneath all of them — how a system establishes who you are and keeps that fact secure over time. Chapter 1 sets the vocabulary precisely (the most-confused pair in security: authentication vs authorization) and frames the threat model the rest of the course defends against.

Authentication vs Authorization — The Core Distinction

These two are constantly conflated, abbreviated confusingly (AuthN and AuthZ), and even share the prefix "auth" — but they answer entirely different questions:

This course focuses on authentication and the session that follows it — establishing identity and keeping that established identity secure. (Authorization — roles, permissions, access control — is a large topic in its own right; we touch it only where the two interact.)

The Three Factors of Authentication

Authentication works by checking one or more factors — categories of evidence that you are who you claim. There are three classic types:

Multi-factor authentication (MFA) means combining factors from different categories — e.g. a password (know) plus a phone code (have). Two passwords aren't MFA; they're the same factor twice. The power of MFA is that an attacker must compromise independent channels — knowing your password is useless without also having your phone (Chapter 6 goes deep).

The Wider Picture: Identity, AuthN, AuthZ, Accountability

Authentication sits in a chain of four related concepts. Keeping them distinct clarifies a lot of security design:

• Identification — claiming an identity ("I'm user philip"). Just a claim, unverified.
• Authentication — proving that claim (the password/passkey checks out).
• Authorization — granting access based on the proven identity ("philip may edit posts").
• Accountability — logging what the identity did, so actions can be traced (audit logs).

The Threat Model: What Attackers Want

Auth security is best understood by what an attacker is trying to achieve. The overarching goal is account takeover — operating as a legitimate user — and there are several routes to it:

Where This Fits With the Other Three Courses

This course completes a quartet — each protects a different part of the same login-and-session lifecycle:

Hands-On Exercises

The single highest-impact decision in authentication is how you store passwords — because databases get breached, and when one does, the difference between "annoying" and "catastrophic" is entirely down to this. The rule is simple to state and surprisingly often gotten wrong: never store passwords; store a slow, salted hash of them. This chapter explains every word of that.

Rule Zero: Never Store the Password Itself

You do not need to know a user's password — you only need to verify that someone presenting a password knows the same one. That means you never store the password (plaintext), and you never store something reversible back to the password either. When a user logs in, you apply the same one-way transform to what they typed and compare the results.

Hashing vs Encryption

But Not Just Any Hash: Fast Hashes Are the Wrong Tool

Reaching for SHA-256 or (worse) MD5 seems reasonable — they're one-way. The problem: those are fast hashes, designed to digest data quickly. For passwords that speed is a liability, because it lets an attacker who steals the hashes try billions of guesses per second on a GPU.

Two Attacks Fast Hashes Enable

• Brute force / dictionary attacks — try every common password (and variations) against a stolen hash. At billions/sec, weak passwords fall in seconds.
• Rainbow tables — giant precomputed tables mapping common-password hashes back to the password, so the attacker doesn't even compute — they just look up. This works because the same password always produces the same hash. Salting defeats this.

Salt: Defeating Precomputation & Identical-Password Leakage

A salt is a unique, random value generated per user and combined with the password before hashing. It's stored alongside the hash (it's not secret). Two effects, both crucial:

• Defeats rainbow tables — precomputed tables are useless because the attacker would need a separate table for every possible salt. They're forced to attack each hash individually.
• Hides identical passwords — two users with the same password get different hashes (different salts), so a breach doesn't reveal "these 500 accounts all use password123."

Slow Hashes: bcrypt, scrypt, Argon2

The real defence is a password hashing function deliberately engineered to be slow and resource-intensive, with a tunable cost you raise as hardware gets faster:

The cost factor is the key tunable: bcrypt's work factor of 12 means 2¹² internal iterations. Each +1 doubles the time. You set it so a single hash takes a noticeable fraction of a second on your server — trivial for one legitimate login, but devastating to an attacker trying billions of guesses. As hardware improves, you raise it. Memory-hardness (scrypt/Argon2) goes further: requiring lots of RAM per guess neutralizes the massive parallelism of GPUs and custom cracking hardware.

Don't Roll Your Own — and Verify in Constant Time

Use a vetted library (bcrypt, argon2 for Node; your framework's built-in). Two operational notes: the library's compare/verify function does a constant-time comparison (to avoid timing leaks), and you should plan to upgrade hashes over time — on successful login, if the stored hash used an old algorithm or low cost, re-hash the password with the current parameters and save it.

Hands-On Exercises

Chapter 2 made stolen hashes hard to crack. This chapter defends the live login endpoint — where attackers don't need your database, they just guess against your form. The attacks differ in how they guess, and the defences differ accordingly, but they share a theme: make guessing slow, costly, and visible.

The Family of Guessing Attacks

Defence 1: Rate Limiting

The first line of defence is limiting how many login attempts a given source can make in a window. Track attempts and reject once a threshold is exceeded:

Rate limit on multiple keys — by IP, by account, and ideally combinations — because each alone has a gap: per-account limits don't stop spraying (one try per account across thousands), and per-IP limits don't stop a botnet (one try per IP across thousands of IPs). Pair coarse IP limits with per-account limits to cover both.

Defence 2: Account Lockout — Carefully

Locking an account after N failed attempts is classic, but it's a double-edged sword:

Defence 3: Don't Leak Which Part Was Wrong (User Enumeration)

A subtle but important defence: your login (and signup, and password-reset) responses must not reveal whether a username exists. Compare:

Distinct messages let an attacker enumerate valid accounts (which then makes credential stuffing and spraying far more efficient — they only target real accounts). Beyond the message text, watch for timing leaks: if a valid username runs the slow password hash but an invalid one returns instantly, the response-time difference reveals validity. Mitigate by running a dummy hash comparison even when the user doesn't exist, so both paths take similar time. The same generic-response discipline applies to signup ("if that email is new, we've sent a link") and password reset ("if that account exists, we've emailed instructions").

Defence 4: CAPTCHA & Step-Up Friction

Introduce friction that's cheap for humans but expensive for bots — after signs of abuse rather than on every login (to avoid harming UX). A CAPTCHA (or a modern proof-of-work / risk-based challenge) triggered after a few failures, or for traffic from suspicious IP ranges, sharply raises the cost of automated guessing. Risk-based authentication goes further: challenge harder when the login looks unusual (new device, new country, impossible travel) and stay frictionless when it looks normal.

Defence 5: Breached-Password & Strength Checks

Stop bad passwords at the source. Modern guidance (NIST) favours checking new passwords against breach corpora rather than imposing arbitrary composition rules:

• Block known-breached passwords — services like Have I Been Pwned's k-anonymity API let you reject passwords that appear in breach datasets without sending the password itself. This directly defangs credential stuffing.
• Encourage length over complexity — long passphrases beat short "P@ssw0rd!"-style strings; the old "must have an uppercase, number, and symbol" rules push users toward predictable patterns.
• Don't force frequent rotation — mandatory periodic changes lead to weaker, incremental passwords (Spring2024! → Summer2024!); rotate only on suspected compromise.

Hands-On Exercises

Authentication (Chapters 2–3) happens once, at login. But HTTP is stateless — every request is independent, with no memory of the last. So how does the server know that this request comes from someone who logged in five minutes ago? The answer is the session: the mechanism that carries "you are logged in" across many stateless requests. This is the thing all three previous courses kept calling "the session."

The Problem: HTTP Has No Memory

Each HTTP request stands alone. Without a session, a user would have to send their password on every single request — terrible for security (the credential constantly in flight) and UX. The session solves this: log in once, then prove "I'm still that logged-in user" cheaply on each subsequent request, without resending the password.

The Session ID: A Bearer Token for "Logged In"

After a successful login, the server creates a session and issues a session ID — a long, random, unguessable string. The client sends that ID back on every request, and the server uses it to recognize the user. The login lifecycle:

Cookies: The Usual Session Carrier

The session ID needs somewhere to live in the browser and ride along on requests. The standard home is a cookie, because cookies are sent automatically by the browser to their origin — the user (and the app code) doesn't have to attach the ID manually:

That "sent automatically" property is convenient — and is precisely the double-edged sword behind CSRF (the cookie rides even on forged cross-site requests). The cookie's security attributes — HttpOnly, Secure, SameSite — are what make it safe to carry a session ID; they get their own deep treatment in the next chapter. (Session IDs can also be carried in other ways — e.g. an Authorization header for APIs — covered with tokens in Chapter 7.)

Where the Session Data Lives: Server-Side vs Client-Side

There are two fundamentally different models for where the actual session state is stored. This is one of the most important architectural choices in auth:

Server-Side Sessions (the classic, default model)

The cookie holds only a meaningless random ID; all the real data (user ID, roles, login time) lives on the server, keyed by that ID. This is the traditional approach (PHP sessions, Express express-session, Rails) and the safest default. Its standout advantage: instant revocation — to log someone out everywhere (or kill a stolen session), you just delete the server-side record and the ID becomes worthless.

Client-Side Sessions (stateless)

The cookie (or token) contains the session data itself, protected by a cryptographic signature so the client can't tamper with it. The server stores nothing — it just verifies the signature and reads the data. This scales beautifully (no shared session store) and is the model behind JWTs (Chapter 7).

What Makes a Good Session ID

• High entropy — long and generated by a cryptographically secure RNG (≥128 bits), so it can't be guessed or brute-forced.
• Opaque — meaningless and random; it should encode nothing (not the user ID, not a counter). A predictable or sequential ID is a catastrophe (Exercise 3).
• Unique — never reused across sessions or users.
• Generated by the framework — use your framework's session machinery (it uses a CSPRNG); never hand-roll IDs from timestamps, counters, or Math.random().

Hands-On Exercises

The session ID is a bearer token (Chapter 4) — hold it and you're the user. This chapter is about protecting that token through its whole life: stopping it being planted (fixation), stolen (hijacking), or kept alive too long (timeouts), and configuring the cookie that carries it. This is where the HttpOnly / Secure / SameSite advice from the HTTPS, CSRF, and XSS courses finally comes home — on the session cookie.

Session Hijacking: Stealing the Token

Session hijacking means obtaining a valid session ID and using it to impersonate the user. The token can be stolen several ways — each of which a previous course addressed:

Session Fixation: Planting a Known Token

A more subtle attack. Instead of stealing your session ID, the attacker gives you one they already know, then waits for you to log in with it:

Session Rotation More Broadly

Regenerating the ID isn't only for login. Good practice rotates the session ID at key moments to limit the value of any single captured token:

• At login — defeats fixation (above); the most important one.
• At privilege elevation — e.g. entering an admin area or re-authenticating for a sensitive action.
• Periodically — some apps rotate the ID every N requests/minutes, so a stolen ID has a short useful life (balance against UX/complexity).
• On logout — fully destroy the server-side session, don't just clear the cookie (next section).

Timeouts: Idle vs Absolute

A session shouldn't live forever — a stolen or abandoned session is a standing risk. Two complementary timeouts:

Use both: idle timeout for the common "forgot to log out" case, and an absolute cap so an attacker who steals a session can't keep renewing it indefinitely by staying active. Sensitive apps (banking) use short timeouts; consumer apps balance security against the annoyance of frequent re-login. Pair timeouts with proper logout: destroy the server-side session record and clear the cookie — clearing only the cookie leaves a valid session on the server that a stolen ID could still use.

The Cookie Flags — In Full, at Last

Everything in this course's quartet converges on these attributes of the session cookie. Set all of them:

Hands-On Exercises

Chapter 3 ended on a promise: passwords alone are guessable, stuffable, and phishable, but MFA changes the game — a correct password is no longer enough. This chapter covers the second-factor options, from the common (TOTP apps) to the gold standard (passkeys/WebAuthn), and is honest about which are strong and which only look strong (SMS).

Why MFA Works

Recall the factor categories (Chapter 1): knowledge (know), possession (have), inherence (are). MFA requires factors from different categories, so an attacker must compromise independent channels. Your phished or stuffed password (knowledge) is useless without also defeating your possession/inherence factor. That independence is the entire value — it's why MFA is the single highest-leverage account-security control.

The Second-Factor Options

TOTP — Time-Based One-Time Passwords

The familiar 6-digit authenticator-app code (Google Authenticator, Authy, etc.). At setup, the server and the app share a secret (shown as a QR code). Both then compute the same code from HMAC(secret, current_30-second_time_window) — so the code changes every 30 seconds and the app needs no network connection:

TOTP is a solid, ubiquitous improvement over passwords alone. Its limits: the shared secret exists on the server (a breach could expose it), and — crucially — the code can be phished. A fake login page can ask for your password and your current TOTP code and relay both to the real site in real time. TOTP raises the bar a lot, but a determined phisher can defeat it.

The SMS Problem

Push Notifications & MFA Fatigue

"Approve this login?" push prompts are convenient, but they introduced a new attack: MFA fatigue (push bombing). An attacker with your password triggers login repeatedly, spamming your phone with approval prompts until you tap "Approve" out of annoyance or confusion (this was the vector in several high-profile 2022 breaches). The mitigation is number matching — the screen shows a number you must type into the app, so you can't approve blindly — plus rate-limiting prompts and showing context (location, app).

WebAuthn / Passkeys — The Gold Standard

WebAuthn (the web standard behind passkeys) is fundamentally stronger because it's built on public-key cryptography and is phishing-resistant by design. At registration your device (phone, laptop, or a hardware key like a YubiKey) generates a key pair: the private key never leaves the device, and the site stores only the public key. At login, the site sends a challenge, the device signs it with the private key (after a local biometric/PIN unlock), and the site verifies the signature.

Recovery Codes — The Backup You Must Plan For

MFA introduces a new failure mode: what if the user loses the factor (lost phone, dead hardware key)? Without a recovery path they're locked out; with a weak one, you've added a back door. The standard answer is one-time recovery codes — a set of single-use backup codes generated at MFA setup, shown once, that the user stores safely.

Hands-On Exercises

Chapter 4 introduced the stateless (client-side) session and promised to return to it. Here it is. Token-based authentication — most commonly with JWTs — replaces the server-side session lookup with a self-contained, signed token the client carries. It's the backbone of APIs and SPAs, and it's powerful, but it has sharp edges: signing pitfalls, storage dilemmas, and the revocation problem from Chapter 4.

What a JWT Is

A JSON Web Token is three Base64URL parts joined by dots: header.payload.signature. The header names the signing algorithm, the payload holds claims (who the user is, when it expires), and the signature proves the token was issued by the server and not tampered with:

Access Tokens & Refresh Tokens

The standard pattern splits responsibilities across two tokens to balance the stateless-vs-revocation trade-off (Chapter 4):

The logic: the access token is short-lived so a stolen one is only useful briefly (mitigating the revocation problem), while the refresh token is long-lived but tightly guarded and revocable — typically tracked server-side so it can be invalidated. This gives you most of stateless scaling with a practical revocation path.

JWT Signing Pitfalls

JWTs have a notorious history of implementation flaws. The classics:

The Revocation Problem — and How Tokens Address It

A pure JWT is valid until it expires; you can't "delete" a self-contained token (Chapter 4). For logout, stolen-token response, or "ban this user now," you need a strategy:

• Short access-token lifetimes — the simplest mitigation; a stolen access token dies in minutes. The window, not the token, is what you control.
• Revocable refresh tokens — store refresh tokens server-side (a small amount of state) so you can revoke them; on logout/compromise, delete them and the user can't get new access tokens.
• A denylist / blocklist — keep a list of revoked token IDs (the jti claim) checked on each request — but this reintroduces server-side state and a lookup, partly defeating statelessness.
• Token versioning — store a per-user token version; bump it to invalidate all that user's tokens at once (e.g. on password change).

Where to Store Tokens (the Cookie vs localStorage Debate)

This connects straight back to the CSRF and XSS courses — there's a genuine trade-off, not a single right answer:

Storing the token in an HttpOnly cookie protects it from XSS theft but reintroduces CSRF (the cookie auto-sends) — so you add SameSite + CSRF tokens. Storing it in localStorage and sending it in an Authorization: Bearer header avoids classic CSRF but exposes the token to any XSS. As the CSRF course concluded: there's no "JWT = safe" — the risk tracks where you store it. For browser apps, an HttpOnly cookie (plus CSRF defences) is often the safer default, because XSS theft of a bearer token is full account takeover with no expiry help.

JWT vs Server-Side Sessions — When to Use Which

Don't reach for JWTs reflexively. For a single monolithic web app, classic server-side sessions (Chapter 4) are simpler, instantly revocable, and perfectly scalable with a shared store — often the better choice. JWTs shine for stateless APIs, microservices, and cross-service auth where avoiding a shared session lookup genuinely matters. Choose by your architecture, not by fashion.

Hands-On Exercises

"Sign in with Google." "Allow this app to access your calendar." These are OAuth 2.0 and OpenID Connect at work — the protocols for letting one app act on your behalf at another without giving it your password. They're widely used and widely misunderstood, starting with the most important distinction: OAuth is about authorization, OIDC adds authentication.

The Problem OAuth Solves: Delegated Access Without Sharing Passwords

Suppose a photo-printing app wants to access your Google Photos. The naive (terrible) way: you give the app your Google password. Now it can do anything as you, forever, and you can't revoke it without changing your password. OAuth 2.0 solves this: it lets you grant the app limited, revocable access to specific resources, without ever sharing your credentials. The app gets an access token scoped to just what you approved.

The Four Roles

OAuth Is Authorization — OIDC Adds Authentication

The Authorization Code Flow (with PKCE)

The recommended flow for web and mobile apps. The key idea: the app never sees your password, and the powerful token is exchanged through a back channel, not exposed in the browser. Step by step:

Scopes: Least Privilege for Delegated Access

A scope is a named permission the client requests (photos.read, calendar.write, email). The consent screen shows you exactly what you're granting, and the token is limited to those scopes. This is least privilege applied to delegation: request only the scopes you actually need, and users (rightly) distrust apps asking for more than they should. Over-broad scope requests are both a security risk and a conversion killer.

Common Misconfigurations

Social Login: What You Gain and Give Up

"Sign in with Google/Apple/GitHub" (OIDC) means users don't create yet another password, you don't store credentials, and you inherit the provider's strong authentication (their MFA, their anti-abuse). The trade-offs: you depend on the provider (outages, account bans, policy changes cascade to your users), you share some user data with them, and you must still handle account linking (same person, multiple providers) and the case where a user loses access to their provider account. For many apps it's a net win; weigh it deliberately rather than adding every provider button reflexively.

Hands-On Exercises

Every chapter so far has secured the front door. This chapter secures the side door — account recovery — and it's the one attackers love most, because a recovery flow is a deliberate way to gain access without the original credential. Get it wrong and all your strong passwords, MFA, and session hardening are bypassed. This is the chapter the CSRF course's "change email → password reset → takeover" chain has been pointing at all along.

The Secure Password-Reset Flow

The correct shape uses a secure, single-use, expiring token delivered out-of-band (email), never a security question or a guessable code:

Reset-Token Design — The Details That Matter

Don't Use Security Questions

"What's your mother's maiden name?" / "First pet?" are knowledge factors (Chapter 1) that are often public or guessable — found on social media, in public records, or simply common (a handful of pet names cover most answers). They're a weak recovery method that has enabled many real takeovers. Avoid them; if a legacy system has them, treat them as one weak signal among several, never as the sole gate.

Email Verification

Verifying a new user actually controls the email they signed up with uses the same token mechanism, and matters for several reasons: it confirms the address is reachable (so recovery works), prevents signups under someone else's email, and reduces spam/abuse accounts. The flow mirrors reset: generate a high-entropy token, store it hashed with an expiry, email a single-use verification link, and mark the address verified when clicked. Keep responses generic (don't reveal "this email is already registered" to a stranger — that's enumeration, Chapter 3).

Re-Verification & Notifications for Sensitive Changes

Recovery security extends to changing the recovery channels themselves — the exact step the CSRF takeover chain exploited:

• Re-authenticate for sensitive changes — require the current password (or an MFA challenge) before changing email, password, or MFA settings. A forged or session-riding request then can't succeed (CSRF/XSS courses).
• Notify on every security change — email the user (at the old address too, for an email change) when the password, email, or MFA is changed, so an unauthorized change is at least visible and reversible.
• Invalidate sessions on password reset — after a reset, kill all existing sessions, so an attacker who had a session is logged out by the legitimate recovery.
• Cool-down / delayed change for email — some systems delay or allow a grace-period reversal of an email change, blunting silent takeover.

Hands-On Exercises

The finale turns the course into practice: how to test an authentication system, the broken-auth patterns to recognize, and a single deployable checklist that pulls all ten chapters — and the whole HTTPS/CSRF/XSS quartet — together.

How to Test Authentication

Auth testing is mostly about probing each part of the lifecycle for the weaknesses each chapter named:

• Password storage — confirm hashes are slow + salted (bcrypt/argon2), not MD5/SHA; that you never store or log plaintext.
• Login — try brute force / stuffing against rate limits; check for user enumeration via messages and timing; confirm generic errors.
• Session — verify the ID is high-entropy & regenerated at login (fixation); check cookie flags; test idle/absolute timeout and that logout truly invalidates server-side.
• MFA — confirm it can't be skipped by manipulating the flow; test recovery-code handling; check for MFA-fatigue protections.
• Tokens — try alg:none and algorithm swaps; tamper with claims; check token expiry/revocation actually works.
• Recovery — test token entropy/expiry/single-use, Host-header poisoning, and that sensitive changes re-authenticate.

The Broken-Auth Catalogue

The Hardening Checklist

How the Course (and Quartet) Fits Together

The arc: establish identity (Ch. 1 foundations, Ch. 2 password storage, Ch. 3 login defences), carry it (Ch. 4 sessions, Ch. 5 session security), strengthen it (Ch. 6 MFA), scale it (Ch. 7 tokens, Ch. 8 OAuth/OIDC), recover it safely (Ch. 9), and verify it all (Ch. 10). And it completes the quartet: HTTPS protects the secret in transit, Authentication establishes and holds it, CSRF stops it being ridden, XSS stops it being stolen. Four courses, one secret, defended end to end.

Hands-On Exercises