Authentication & Access Control

Identification claims who you are (a username). Authentication proves that claim (password, token, biometric). Authorization decides what that identity may do (roles, permissions). They run in that order: identify, authenticate, authorize each action.

A JWT is three dot-joined base64url parts — header.payload.signature. The header names the algorithm, the payload holds claims, the signature covers both. A standard JWT is signed, not encrypted: the payload is readable, only tampering is visible.

Factors are what you know, what you have and what you are. SMS is weakest — codes cross a carrier network you do not control and fall to SIM swap. A one-time password is phishable in real time; only WebAuthn binds to the site origin.

Detect failed-login spikes per account (brute-force) or across accounts (stuffing/spraying). Prevent via throttling, CAPTCHA, dictionary blocking, and MFA. Identical error responses block enumeration; rotate session tokens at login; SameSite + httpOnly cookies.

A passkey is a public-key credential from WebAuthn. The private key stays on the device and only the public key reaches the server, so there is no shared secret to leak or replay. The browser signs only for the registered origin.

The standards body NIST favours a long minimum, a generous maximum, and screening new passwords against breach lists. Composition rules and calendar rotation are discouraged — they drive predictable mutations. Rotate on evidence of compromise.

Role-based access control grants permissions through named roles — easy to audit, but roles multiply as exceptions appear. Attribute-based access control decides per request from user, resource, action and context. Both must default to deny.

A salt is a unique random value stored with the hash, so identical passwords hash differently and rainbow tables fail. A pepper is a secret kept outside the database, so a stolen dump resists it. Both back a slow KDF like Argon2id.

A session id must be long and drawn from a cryptographic random source, never derived from a username or counter, and reissued at login. Send it in a cookie marked Secure, HttpOnly and SameSite so scripts and other sites cannot use it.

Key risks — alg=none accepted, HS/RS algorithm confusion, weak HMAC secrets, missing or unbounded exp, sensitive data in the readable payload, and an unvalidated kid header. Fix by pinning the algorithm, validating exp, and using strong keys.

Store the JWT in an httpOnly + secure cookie or in memory — not in localStorage, which any JavaScript reads, so one XSS steals the token. An httpOnly cookie is invisible to JS but sent automatically, so it needs CSRF protection (SameSite). Note: httpOnly/secure are cookie attributes, not applicable to localStorage.

A timestamp /restore/<id> is predictable — use an unguessable random token, single-use, short TTL. Identical responses block enumeration; build the URL from config, not the Host header. Rate-limit OTP sends and wrong entries, set a TTL, cap retries.

Stuffing replays breached pairs one try per account, so per-account counters barely fire. Hard lockout then becomes a weapon — an attacker locks real users out on purpose. Prefer graduated throttling, device and network signals, and risk-based MFA.

Each SMS costs money, so flooding the code-request endpoint burns budget. Gate SMS behind a first factor so anonymous users cannot trigger it, prefer push, rate-limit per user/IP/device (especially codes never entered), detect anomalies, use a WAF.

Recovery is a second door into the account, so the system is only as strong as its weakest path — a mailbox reset undoes a security key. Hold recovery to the primary bar: verified channels, a delay plus notification before an MFA reset, and audit.

The handler reuses the identifier the visitor arrived with, so whoever planted it owns the authenticated session — classic fixation; logout only blanks a field. Regenerate on login and privilege change, destroy on logout, harden the cookie.

Give each workload its own verifiable identity — mutual TLS certificates or short-lived tokens from a platform identity service — instead of one API key in config. Credentials rotate automatically, are scoped narrowly and revocable without a redeploy.

Ship both: an idle timeout ends a forgotten session, an absolute one caps how long a stolen token stays useful. Invalidate server-side on logout, password reset and privilege change, and offer logout-everywhere. Stateless tokens need short lives.

One identity provider fronts every application, so a forged assertion or a compromised provider admin reaches all at once. Contain it with phishing-resistant MFA on the provider, short assertion lives, per-application audience and scope, and revocation.

Trigger step-up only on the sensitive operation set. Require a phishing-resistant factor where one is enrolled, else the one-time password. Bind the result to the session and to that exact operation for a short window, never a global elevated flag, and audit actor, factor and outcome.