Chapter 1: The Three Factors, Reconsidered#

Every authentication scheme reduces to combinations of three classic factors, plus two modern additions:

• Something you know - passwords, PINs, passphrases.
• Something you have - a hardware key, a phone, a smart card.
• Something you are - fingerprint, face, iris.
• Somewhere you are - geolocation / network context (a contextual signal, not a hard factor).
• Something you do - behavioral biometrics: typing cadence, mouse dynamics.

The Hacker’s View: Each factor has a native attack. Knowledge factors are phished and sprayed. Possession factors are stolen or SIM-swapped. Inherence factors are spoofed (a lifted fingerprint, a printed face) and, crucially, cannot be rotated once compromised, you get ten fingerprints for life.

The Defender’s View: Multi-Factor Authentication (MFA) works because the attacker must now compromise factors of different kinds simultaneously. But not all MFA is equal. This is the single most important nuance defenders miss:

quadrantChart
    title Phishing Resistance vs. User Friction of Auth Methods
    x-axis Low Friction --> High Friction
    y-axis "Weak (Phishable)" --> "Strong (Phish-Resistant)"
    quadrant-1 Gold Standard
    quadrant-2 Secure but Clunky
    quadrant-3 Legacy - Retire
    quadrant-4 Convenient but Risky
    Password only: [0.15, 0.08]
    SMS OTP: [0.35, 0.22]
    TOTP App: [0.45, 0.40]
    Push Approve: [0.25, 0.35]
    "Passkey (FIDO2)": [0.20, 0.92]
    Hardware Key: [0.55, 0.95]

The lesson from the chart: SMS-based OTP is MFA, but it is weak MFA. It resists password reuse but not a real-time phishing proxy or a SIM swap. Only FIDO2 / WebAuthn credentials, where the private key never leaves the authenticator and the signature is cryptographically bound to the origin, are genuinely phishing-resistant ².

MFA fatigue is a real attack

In 2022, several high-profile breaches used push-bombing: the attacker already has the password, then spams the victim with approval prompts until, out of annoyance or confusion, they tap “Approve.” Push-based MFA without number matching is a design flaw, not a security control. Prefer passkeys, or enforce number matching plus context (app name, location) on every prompt. ³

Chapter 2: Passwords That Refuse to Die#

Even in a passkey future, password databases will exist for a decade. Storing them correctly is non-negotiable.

The rule: never store what the user typed. Store a slow, salted, memory-hard hash.

where $m$ is memory cost (KiB), $t$ is time cost (iterations), and $p$ is parallelism. Argon2id is the current OWASP-recommended default because it resists both GPU cracking (via memory hardness) and side-channel attacks (via its hybrid data access pattern) ⁴.

Why slow hashing matters, expressed as attacker economics. If an attacker can compute $R$ hashes per second, cracking a password drawn uniformly from a keyspace of size $N$ takes, on average:

A fast hash like unsalted SHA-256 gives a modern GPU rig $R \approx 10^{11}$ guesses/second. A tuned Argon2id can drop that to $R \approx 10^{3}$. That eight-order-of-magnitude collapse in $R$ is the entire game.

The password storage checklist

1. Hash with Argon2id (or scrypt / bcrypt if Argon2 is unavailable).
2. Salt uniquely per user (defeats rainbow tables).
3. Consider a server-side pepper stored in an HSM/KMS, separate from the database (defeats an attacker who dumps only the DB).
4. Never cap password length aggressively or forbid paste, both push users toward weaker secrets.
5. Check new passwords against breach corpora (e.g., HaveIBeenPwned’s k-anonymity API) ⁵.

Chapter 3: The Passwordless Endgame - WebAuthn & Passkeys#

WebAuthn (the browser API) plus CTAP (the authenticator protocol) together form FIDO2. The mental model:

sequenceDiagram
    participant U as User
    participant B as Browser (WebAuthn)
    participant A as Authenticator
    participant RP as Relying Party (Server)

    Note over U,RP: Registration
    RP->>B: challenge + rp.id + user.id
    B->>A: create credential for rp.id
    A->>A: generate keypair, store private key
    A-->>B: public key + attestation + credentialId
    B-->>RP: store public key against user

    Note over U,RP: Authentication
    RP->>B: challenge (random nonce)
    B->>A: sign challenge (bound to origin)
    A->>U: verify presence (touch / biometric)
    A-->>B: signature over challenge
    B-->>RP: assertion
    RP->>RP: verify signature with stored public key

The magic is in one line: the signature is bound to the origin (rp.id). A phishing site at paypa1.com cannot get the authenticator to produce a valid assertion for paypal.com, because the browser refuses to release it. This eliminates the entire category of credential phishing by construction, not by user vigilance ².

A passkey is simply a discoverable, syncable FIDO2 credential, backed up to a cloud keychain (Apple, Google, Microsoft, or a password manager) so it survives device loss. That sync is the ergonomic breakthrough that made passwordless viable for consumers.

Chapter 4: The Models - From Roles to Attributes to Relationships#

mindmap
  root((Access Control))
    DAC
      Owner grants access
      Unix file permissions
    MAC
      System enforces labels
      SELinux / classified systems
    RBAC
      Users to Roles
      Roles to Permissions
      Coarse-grained
    ABAC
      Policy over attributes
      subject / resource / action / context
      Fine-grained, dynamic
    ReBAC
      Graph of relationships
      "is owner of", "is member of"
      Google Zanzibar model

RBAC (Role-Based) is where most organizations live: a user has roles, roles bundle permissions. It is easy to reason about and audit. Its failure mode is role explosion, when “editor for region EU on the finance project during business hours” becomes its own role, you have thousands of them and no one understands the graph.

ABAC (Attribute-Based) solves that by evaluating a policy over attributes at request time:

1
# A tiny ABAC policy (OPA / Rego style)
2
allow if {
3
    input.subject.department == input.resource.owner_department
4
    input.action == "read"
5
    input.context.time_hour >= 9
6
    input.context.time_hour < 18
7
}

ReBAC (Relationship-Based), popularized by Google’s Zanzibar paper ⁷ and open-sourced as systems like OpenFGA and SpiceDB, models authorization as a graph: “Alice is an editor of Doc, Doc is in Folder, Bob is a viewer of Folder → Bob can view Doc.” It shines for the “can user X do Y to object Z?” checks that dominate SaaS products with sharing and nesting.

The IDOR trap - authorization’s most common wound

An Insecure Direct Object Reference (IDOR) is what happens when you authenticate the user but forget to authorize the object. The classic:

1
GET /api/invoices/1043   ->  200 OK  (my invoice)
2
GET /api/invoices/1044   ->  200 OK  (someone else's invoice!)

The fix is a discipline, not a library: every object fetch must be scoped to the requesting principal. Never SELECT * FROM invoices WHERE id = ?; always ... WHERE id = ? AND owner_id = ?, or push the check into a central policy engine. IDOR is the reason Broken Access Control tops the OWASP list. ⁶

Chapter 5: The Principle of Least Privilege, Quantified#

Least privilege says: grant the minimum permissions needed, for the minimum time. In practice, entitlements only ever accumulate, this drift is called privilege creep. A useful mental metric is the ratio of permissions used to permissions granted:

xychart-beta
    title "Privilege Creep - Granted vs. Actually Used Permissions"
    x-axis [Month1, Month3, Month6, Month9, Month12]
    y-axis "Permission Count" 0 --> 120
    bar [20, 45, 70, 95, 115]
    line [18, 30, 34, 38, 40]

The widening gap between the bars (granted) and the line (used) is your standing attack surface: privileges an attacker inherits the moment they compromise the account, and that no one is watching. The countermeasures:

• Just-in-Time (JIT) access: grant elevated rights for a bounded window, then auto-revoke.
• Access reviews / recertification: periodic “do you still need this?” campaigns.
• Privileged Access Management (PAM): vault admin credentials, broker sessions, record everything.

Chapter 6: OAuth 2.0, OIDC, and the Confusion Between Them#

The single most common architectural error in this space is conflating OAuth 2.0 (authorization - delegated access) with OpenID Connect (authentication - proving identity). OIDC is a thin identity layer on top of OAuth 2.0 ⁸.

• OAuth 2.0 answers: “Will you let this app act on your behalf to access resource R?” It issues access tokens.
• OIDC answers: “Who is this user?” It issues an ID token (a signed JWT with claims about the user).

The modern, recommended flow for essentially everything, SPAs, mobile, and web apps alike, is Authorization Code + PKCE:

sequenceDiagram
    participant U as User
    participant App as Client App
    participant AS as Authorization Server
    participant API as Resource Server

    App->>App: generate code_verifier + code_challenge (S256)
    App->>AS: /authorize?code_challenge=...&scope=openid
    AS->>U: login + consent
    U->>AS: authenticate (MFA)
    AS-->>App: authorization code (short-lived, single-use)
    App->>AS: /token (code + code_verifier)
    AS->>AS: verify SHA256(verifier) == challenge
    AS-->>App: access_token + id_token + refresh_token
    App->>API: request + Bearer access_token
    API->>API: validate signature, aud, exp, scope
    API-->>App: protected resource

Why PKCE (Proof Key for Code Exchange)? Without it, an attacker who intercepts the authorization code (via a malicious app registered on the same URI scheme, say) could redeem it. PKCE binds the code to a secret (code_verifier) that only the legitimate client knows, so a stolen code is useless. OAuth 2.1 makes PKCE mandatory for all clients and removes the dangerous implicit and password grant types entirely ⁹.

Stop using the Implicit flow

The legacy Implicit grant returned tokens directly in the URL fragment, a design from an era before browsers had fetch and CORS. Tokens leaked into history, referrers, and logs. If a tutorial tells you to use response_type=token, the tutorial is a decade out of date. Authorization Code + PKCE, always.

Chapter 7: Sessions vs. Tokens - The Stateful/Stateless Tradeoff#

The industry-standard compromise: short-lived access tokens (5–15 min) + long-lived refresh tokens. The access token is a JWT you never revoke (it expires fast anyway); the refresh token is a revocable, rotating credential held server-side. Revoking a user cuts them off within one access-token lifetime.

The three JWT footguns

1. alg: none - historically, some libraries accepted a token that declared it needed no signature. Always pin the expected algorithm server-side; never trust the header’s alg.
2. HS256 vs RS256 confusion - an attacker submits an HS256 token signed with your public RSA key as the HMAC secret. Pin the algorithm.
3. Storing JWTs in localStorage - readable by any XSS payload. Prefer HttpOnly, Secure, SameSite cookies for browser sessions. ¹⁰

Chapter 8: Federation & SSO#

Single Sign-On (SSO) lets one login serve many applications. The two dominant protocols:

• SAML 2.0 - XML-based, verbose, still dominant in enterprise B2B and legacy systems.
• OIDC - JSON/JWT-based, the default for new applications, mobile, and APIs.

The player list: an Identity Provider (IdP) - Okta, Entra ID, Keycloak, Google - authenticates the user and vouches for them to a Service Provider (SP) / Relying Party. The value is centralized: one place to enforce MFA, one place to disable a departing employee, one audit trail.

Deprovisioning is the silent killer

SSO’s greatest security benefit is instant, central offboarding. The most common real-world failure is the orphaned account, an employee leaves, HR closes the SSO account, but a local admin account on some forgotten server lives on. Reconcile every identity source against your HR system of record. An account no human owns is an account an attacker owns.

Chapter 9: PKI and the Chain of Trust#

Machine-to-machine trust is built on X.509 certificates and Public Key Infrastructure. A certificate binds a public key to an identity, signed by a Certificate Authority (CA) the verifier trusts.

graph TD
    RootCA["Root CA<br/>(offline, air-gapped)"] -->|signs| IntCA["Intermediate CA"]
    IntCA -->|signs| Leaf1["service-a.internal<br/>leaf cert"]
    IntCA -->|signs| Leaf2["service-b.internal<br/>leaf cert"]
    Leaf1 -.->|mTLS handshake| Leaf2
    Verify{"Verifier checks:<br/>signature chain +<br/>validity dates +<br/>revocation (OCSP/CRL) +<br/>hostname match"}
    Leaf2 --> Verify
    style RootCA fill:#7c2d12,color:#fff
    style IntCA fill:#9a3412,color:#fff

The root’s private key is the crown jewel, kept offline and air-gapped, because its compromise invalidates everything below it. Intermediates do the day-to-day signing so the root rarely comes out of the vault.

mTLS (mutual TLS) is PKI’s answer to service-to-service auth: both sides present certificates, so a service proves its identity to callers and callees. This is the cryptographic backbone of Zero Trust between workloads (and the reason service meshes like Istio and Linkerd exist, they automate cert issuance and rotation via SPIFFE/SPIRE identities) ¹².

Chapter 10: Secrets Management#

The oldest sin in software: the hard-coded secret.

1
# The vulnerability that never dies
2
DB_PASSWORD = "hunter2"          # committed to git, forever in history
3
API_KEY = "sk_live_a1b2c3d4..."  # leaked in the client bundle

Git never forgets. A secret committed once and “removed” in the next commit is still in the history, still scraped by bots watching public pushes within seconds. The disciplines:

Workload identity beats stored secrets

The best secret is the one you never store. Workload identity federation (AWS IAM Roles for Service Accounts, GCP Workload Identity, OIDC-federated CI runners) lets a workload prove what it is to get short-lived credentials, with no long-lived key sitting anywhere to steal. If you are still pasting static cloud keys into CI, this is your highest-leverage upgrade.