rgoussu.dev
rgoussu@goussu: ~/library/security
❯ ~/library/security cat authentication-and-authorization.md

Authentication & authorization

# Who you are vs. what you may do — sessions, JWTs, OAuth2/OIDC flows, MFA, and authorization models that scale.

Conceptsaved 2026-08-08 #auth#oauth#oidc#jwt#security#identity

Overview

Authentication (proving who you are) and authorization (deciding what you may do) are distinct problems chronically conflated. Between password storage, session mechanics, token formats, and the OAuth2/OIDC protocol family, this is the security area a backend engineer touches most often — and the one where "rolled our own" causes the most damage. The design space is well mapped; the job is knowing which standard solution fits.

Key points

  • Passwords & MFA: store only slow adaptive hashes (argon2id, bcrypt — never fast hashes); MFA via TOTP or, better, phishing-resistant WebAuthn/passkeys, which bind credentials to the origin and are quickly becoming the default answer.
  • Sessions vs. tokens: server-side sessions (cookie carries an ID; revocable, simple — underrated) vs. self-contained tokens (JWT: claims signed by the issuer; verifiable without a lookup, but not revocable before expiry). Rule of thumb: sessions for first-party web, short-lived JWTs + refresh tokens for APIs and distributed validation.
  • JWT pitfalls: alg confusion (never accept none, pin the algorithm), no revocation story (keep lifetimes short), claims validation (aud/iss/exp) skipped, secrets in payload (it's encoded, not encrypted).
  • OAuth2 is delegation, OIDC is authentication: OAuth2 lets a client act on a user's behalf against a resource server (access tokens, scopes); OIDC adds the ID token and standard claims to make it a login protocol. "Login with Google" is OIDC; calling the Drive API afterward is OAuth2.
  • The flows that matter now: Authorization Code + PKCE for everything user-facing (SPAs and mobile included — implicit flow is dead); Client Credentials for service-to-service; Device flow for TVs/CLIs. Refresh-token rotation with reuse detection.
  • Authorization models: RBAC (roles → permissions; start here), ABAC (attributes/ policies), ReBAC (relationships — Google Zanzibar lineage, e.g. OpenFGA) for document/org-chart sharing semantics; centralize the decision (policy engine) rather than scattering if statements.
  • Machine identity: mTLS / SPIFFE and workload identity federation replacing long-lived API keys between services.
  • To explore: SAML (enterprise SSO's legacy standard), session fixation & token binding, fine-grained authorization latency trade-offs, OIDC token exchange.

Practice

  • PortSwigger Authentication labs (source) — attack login, MFA, and session logic to internalize what "rolled our own" breaks.
  • PortSwigger JWT labs (source) — exploit alg confusion, none, and unverified signatures — the pitfalls list turned into hands-on breakage.
  • PortSwigger OAuth labs (source) — walk the flaws in real OAuth flows (redirect_uri, state, token leakage).
  • OpenID Connect Playground (source) — step through an auth-code flow end to end and inspect the ID token's claims.
  • Build your own login (source) — implement Authorization Code + PKCE against a real IdP, then verify the JWT server-side (pinned alg, checked aud/iss/exp) — proves you understand delegation vs. authentication.
  • RealWorld full-stack build (source) — JWT issuance, KDF password storage, and domain-enforced authorization inside a full product build.

Related