Foundations
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:
| Authentication (AuthN) | Authorization (AuthZ) | |
|---|---|---|
| Question | Who are you? | What are you allowed to do? |
| Verifies | your identity (you are who you claim) | your permissions (you may access X) |
| Happens | first — at login | after — on each protected action |
| Example | entering a correct password / passkey | being allowed into the admin panel |
| Failure looks like | "Login failed" (401 Unauthorized) | "Access denied" (403 Forbidden) |
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:
| Factor | "Something you…" | Examples |
|---|---|---|
| Knowledge | know | password, PIN, security question |
| Possession | have | phone (TOTP app), security key, passkey |
| Inherence | are | fingerprint, face, biometric |
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:
| Attacker goal | How | Course chapter |
|---|---|---|
| Steal the credential | phishing, breach reuse, weak password storage | 2, 3 |
| Guess the credential | brute force, credential stuffing, spraying | 3 |
| Steal the session | session hijacking, XSS, fixation | 4, 5 |
| Bypass MFA | SMS interception, MFA fatigue, phishing proxies | 6 |
| Abuse tokens | JWT flaws, stolen refresh tokens, OAuth misconfig | 7, 8 |
| Hijack recovery | weak password-reset / email-verification flows | 9 |
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:
| Course | Protects | Against |
|---|---|---|
| HTTPS / TLS | the credential/session in transit | eavesdropping, tampering on the wire |
| Authentication (this) | establishing & holding the identity | credential theft, session hijacking, weak MFA |
| CSRF | against abuse of an active session | forged requests riding the session |
| XSS | the page that holds the session | script stealing/riding the session |
HttpOnly, Secure, SameSite — that appeared in all three previous courses lives here, on the session cookie, and Chapter 5 finally ties it together. Account security is only as strong as the weakest link across all four.
Hands-On Exercises
Classify each as Authentication or Authorization: (a) the site rejects your password; (b) you're logged in but can't open /admin; (c) a fingerprint unlocks your phone; (d) a regular user is blocked from deleting another user's post. For each, give the likely HTTP status (401 vs 403) and justify it.
For each combination, state whether it's true multi-factor authentication and why: (a) password + SMS code; (b) password + security question; (c) fingerprint + passkey on a hardware key; (d) PIN + password. Name the factor category of each element.
📄 View solutionFor each prior-course attack, state which authentication threat-model goal it serves and why fixing it matters to account security: (a) XSS stealing document.cookie; (b) a CSRF forged "change email"; (c) TLS stripping on a login page. Tie each to "account takeover."
Chapter 1 Quick Reference
- Authentication (AuthN) = "who are you?" (verify identity); Authorization (AuthZ) = "what may you do?" (verify rights)
- AuthN always comes first; mnemonic: autheNtication = ideNtity, authoRization = Rights
- HTTP 401 "Unauthorized" really means un-authenticated; 403 "Forbidden" means authenticated-but-not-authorized (spec misnomer)
- Three factors: knowledge (know) · possession (have) · inherence (are); MFA = factors from different categories
- Full chain: identification → authentication → authorization → accountability
- Threat model: the goal is account takeover — via stolen/guessed credentials, stolen sessions, bypassed MFA, abused tokens, or hijacked recovery
- This course completes the quartet (HTTPS / Auth / CSRF / XSS) — they interlock; the weakest link sets account security
- Next chapter: password storage done right — hashing vs encryption, salts, and slow hashes (bcrypt/scrypt/Argon2)