Authentication (authN) — who are you?

Showing your passport at the airport — proving you really are the person you claim to be.

This is the concept of Authentication (authN), and it means proving identity: a login, a passkey, a token that says "this really is Alice." It usually happens once per session. Get it wrong and an impostor walks in as someone else. But proving who you are says nothing about what you may do — that's the other question entirely.

Authorization (authZ) — what may you do?

A hotel keycard — it proves nothing about your name, but it opens your room and not the others, and not the manager's office.

This is the concept of Authorization (authZ): deciding what an identity is allowed to do — read this, edit that, never touch the admin panel. Unlike authN, it has to be checked on every request, because one logged-in user may touch a hundred different things. Knowing who someone is is not permission to do anything in particular.

Two layers — never collapse them

A nightclub: the bouncer checks your ID at the door once, and the bartender still checks you're of age every time you order. Two checks, two moments.

The classic mistake is fusing the two — proving identity once and trusting that forever, or stuffing every permission into a login token and never re-checking. AuthN happens at the door; authZ happens at every door inside. Keep them separate, and check the second one constantly.

Don't Roll Your Own Auth — never build your own

You don't weld your own bank vault from sheet metal in the garage — you buy one built and tested by people who do nothing else.

This is the practice of Don't Roll Your Own Auth. Identity is the foundation everything else stands on, and it's brutally easy to get subtly wrong. Use proven standards and libraries — established protocols, a battle-tested auth library or provider — not a clever scheme you invented. The history of security is paved with home-made auth that looked fine until it suddenly wasn't.

The map: 22 concepts in six groups

A keyring: first you see the whole bunch, then you learn which key opens which door.

The course's concepts fall into six groups. Each answers its own question: what the two "auths" are, how to prove identity, how to stay logged in, how to grant access without a password, how to decide permissions, and how it all usually breaks.

Every concept below gets the same treatment: its English name (that's the term you'll search docs for), a picture from life, a diagram, and a card with fields. At the end, a cheat sheet with every concept.

Password Hashing — passwords, the weak default

A secret word shared with the doorman — fine until someone overhears it, guesses it, or you use the same one everywhere.

Passwords are universal and the weakest common factor: reused, guessable, phishable. If you must use them, the non-negotiable rule is never store them as text. Store a slow, salted hash (Argon2, bcrypt) — that's Password Hashing — so a stolen database doesn't hand over everyone's password. (More on that in the mistakes chapter.)

MFA — something you know, have, are

A safe-deposit box needs your key and the bank's key. One alone opens nothing.

MFA (Multi-Factor Authentication), or two-factor, demands a second proof beyond the password — something you have (a code from an app, a security key) or something you are (a fingerprint). Even a stolen password is then useless alone. An authenticator-app code (TOTP) is solid; SMS codes are weak (interceptable) but better than nothing. MFA is the single biggest, cheapest security win you can add.

Passkeys — the passwordless future

A key that only works at the one door it was cut for — fake the website, copy the lock's photo, and the key simply won't turn.

Passkeys (built on the WebAuthn standard) replace passwords with a cryptographic key pair tied to your device and the real site, so there's nothing to phish, reuse, or leak — and Apple, Google, and Microsoft now default to them. The private key never leaves your device; the site only ever sees a signature. This is where authentication is heading: nothing to steal.

Stateless HTTP — HTTP has no memory

A shop where the clerk forgets you the instant you turn around — so you need a ticket to prove, on your next step, that you already paid.

HTTP is stateless: every request is independent; the server doesn't remember that you logged in a second ago. So after authentication you're handed something — a cookie or a token — that you send with each request to say "it's still me." Everything below is two ways to do that. (This is the statelessness from the protocols course.)

Session — the server remembers

A coat check — you hold a little numbered ticket, and all the real information sits behind the counter under that number.

With sessions, the server stores who you are and hands you a cookie holding only a random session id. Each request, it looks the id up. The server is the source of truth, so logging out or banning someone is instant — just delete the session. The cost is that the server must store and look up that state. The right default for most web apps.

JWT — the token carries the truth

A festival wristband with your access level already printed and tamper-sealed on it — the guard checks the seal, not a guest list.

A JWT (JSON Web Token) is a signed token the client holds that contains the identity and its claims; the server just verifies the signature, no lookup needed. That makes it stateless and easy to scale across services — but hard to revoke: a leaked token stays valid until it expires. So you keep lifetimes short and pair it with a refresh token. Great for APIs and microservices; overkill for a simple web app.

httpOnly Cookie — where you keep it matters

A key in a locked drawer versus a key taped to the front door — same key, very different safety.

A token in the browser belongs in an httpOnly cookie (JavaScript can't read it), not in localStorage, where any injected script can steal it. The store is part of the security: get it wrong and one XSS bug hands an attacker every session. How you transport and store the credential is as important as the credential itself.

OAuth 2.0 — grant access without sharing a password

A valet key that starts the car and opens the door, but not the boot or the glovebox — you hand over limited access, not your whole keyring.

This is the OAuth 2.0 protocol. It lets a user grant your app limited access to their account on another service — your app reads their Google Calendar — without ever giving you their Google password. The other service hands your app an access token limited by a scope ("read calendar, nothing else"). It's about delegated authorisation, not identity.

OIDC — OAuth2 that also says who you are

The valet key, now with a photo ID clipped to it — not just "what this key opens," but "and here's who it belongs to."

OAuth2 alone tells you what an app may access, not who the user is. OpenID Connect (OIDC) adds a thin identity layer — an ID token with verified claims (this is Alice, here's her email) — on top. This is what powers "Log in with Google" and single sign-on (SSO). When you want social login or SSO, OIDC is the standard.

API Key — the simple machine credential

A spare key you give a trusted contractor — no name attached, just "whoever holds this may come in."

An API key is a long secret string that identifies a program, not a person — used for service-to-service and programmatic access. Simple and effective, but it is the credential: anyone who finds it is in. So you scope it, rotate it, and never commit it to git or put it in a URL. Good for machines; not a substitute for real user identity.

Deny by Default / Least Privilege — forbidden unless allowed

A new employee's badge that opens nothing until each door is explicitly granted — rather than opening everything until someone remembers to lock a few.

The foundation of authorisation is two rules. Deny by default: everything is forbidden unless explicitly allowed. Least privilege: each identity gets the minimum access it needs, no more. Default-open systems leak — someone always forgets to restrict the new endpoint. Default-closed systems fail safe. Start from "no" and grant deliberately.

RBAC — permissions by role

A theatre where your ticket type — stalls, circle, backstage pass — decides where you can go, without naming you personally.

RBAC (Role-Based Access Control) groups permissions into roles — admin, editor, viewer — and assigns users to roles. Simple, readable, and enough for most apps: "editors can publish, viewers can't." It gets coarse when rules depend on context or on the specific record, which is where the next models come in.

ABAC — permissions by policy

A rule rather than a list — "managers may approve expenses under 10k, in business hours, from a company device" — evaluated fresh each time.

ABAC (Attribute-Based Access Control) decides from attributes of the user, the resource, and the context — role and amount and time and device. Far more flexible than fixed roles, and far more complex. The signal to adopt it: you're stacking more than a couple of custom if conditions onto your role checks.

Ownership Check — can you touch this record?

You have a valid library card (a role), but that doesn't let you read the notes scribbled in someone else's borrowed book.

The ownership check (object-level authorization) is the most-missed check: even a valid "editor" must only edit their own documents, not everyone's. The role says "editors may edit"; you still have to verify this editor owns this row. Forgetting this is the single most common access-control bug — change the id in the URL and you're in someone else's data. Always check the object, not just the role.

Broken Access Control / IDOR — forgetting to check

A building where the front door is guarded but every internal door is unlocked — once you're in, you can walk anywhere.

Broken Access Control is the number-one web vulnerability: an endpoint authenticates the user but forgets to check they're authorised for what they asked. Its commonest form is IDOR (Insecure Direct Object Reference) — changing /orders/123 to /orders/124 and seeing someone else's order, because the server never checked ownership. Breaches of millions of records trace to exactly this. Check authZ on every request, server-side, against the actual object.

Plaintext / Fast Hash — storing passwords wrong

Keeping the spare keys to every house on the street in a glass jar on the porch.

Storing passwords as plaintext — or with a fast hash like MD5 — means one database leak exposes everyone, and reused passwords compromise their other accounts too. Passwords must be slowly and individually hashed (Argon2, bcrypt) so they're expensive to crack even when stolen. The hash being slow is the point, not a flaw.

Token Leakage — leaking and trusting tokens

Writing the alarm code on a sticky note stuck to the door — the lock is fine; you just handed out the secret.

Token leakage is how tokens and keys escape. They leak through URLs (which get logged), browser localStorage (which a script can read), and secrets committed to git. And a token must be verified, not trusted because it showed up — a tampered or expired one must be rejected. Treat every credential as something that will leak someday: short lifetimes, rotation, and never in a place that gets logged or scraped.

Trusting the Client — believing what the browser says

A shop that lets customers write their own price tags and never checks them at the till.

This is the anti-pattern of trusting the client. Anything the client sends — a hidden form field, a role in a cookie, an isAdmin=false flag — can be forged. The browser, the app, the request are all under the user's control. Every real check must happen on the server, which the user can't edit. The client is a suggestion; the server is the authority.

Auth Provider — use a library or a provider

You don't manufacture your own seatbelts — you fit certified ones designed by specialists and crash-tested for years.

For almost everyone, the right move is to not build auth yourself: use your framework's auth, or an auth provider (Auth0, Clerk, Supabase, Cognito, and the like) that handles hashing, sessions, MFA, OAuth, and the edge cases you'd never think of. Your job is to wire it in correctly and own the authorisation — the part only you know.

Match the mechanism to the app

A house key, a car key, and a hotel keycard are all "keys" — you pick by the door, not by fashion.

Sessions for a normal web app (simple, instantly revocable); short-lived JWTs plus refresh when you need stateless scale across services; OIDC for social login and SSO; API keys for machine-to-machine. Add MFA everywhere it matters, especially admin accounts. Choose by the shape of your app, not by what sounds advanced.

How it all connects

A hotel guest's path: a passport at reception, a keycard in hand, and every door decides for itself whether to open.

Login factors (password, MFA, passkey, OIDC, API key) lead to authN. Its result travels with every request in a session or a JWT, best kept in an httpOnly cookie. On every request, authZ decides by roles or policy — and always checks ownership of the object.