Authentication and Authorization

• Separate authentication from authorization and name an incident of each
• Explain MFA and why passwords alone are insufficient
• Describe session and token lifecycle basics securely

• Password reuse and phishing defeat password-only authN at scale; MFA is the standard mitigator.
• AuthZ mistakes (horizontal/vertical privilege escalation, IDOR) are quietly the #1 web flaw.
• Sessions and tokens are the glue: a stolen session token is an authN bypass that no password strength fixes.
• Separating the concepts lets you debug precisely: 'they authenticated fine but couldn't act' is an authZ bug.

Your ID proves who you are (authentication). The door list decides whether you're allowed into the VIP room tonight (authorization). Knowing someone's name is worth nothing if they're not on the list — and being on the list proves nothing about who they are.

• On login, the app verifies credentials (password hash, TOTP, WebAuthn key) — authentication completes.
• A session/token is issued and bound to that identity: cookie, opaque session ID, or signed JWT.
• Every subsequent request carries proof of the session; the app validates it (still authN: 'is this session valid for this user?').
• Authorization then checks the user's roles/claims against the resource's policy ('must be admin of org 42 to PATCH this').
• MFA adds a second factor (something you have/are) so a stolen password alone can't authenticate.
• Federation (SSO/OIDC/SAML) delegates authN to an identity provider, giving central control and logout.

• An app enforces MFA for all logins and then applies row-level authZ per organization in every query — a support rep sees only their org's rows.
• A microservice gateway validates the JWT (authN) then reads the tenant claim to scope database queries (authZ).
• A company moves to SSO via OIDC: password resets, lockouts and MFA enrollments consolidate at the IdP.

• Never store plaintext passwords: hash with a memory-hard algorithm (argon2id/bcrypt) and salt.
• Enable MFA everywhere sensitive, and require it for admins and remote access.
• Enforce authZ server-side on every action — never trust client-side 'user is admin' flags.
• Bind sessions to the session token's origin, rotate on privilege change, and expire them.
• Log authN and authZ events (success, failure, escalation) for triage.

• Treating authZ as 'the front end hides the delete button' — an attacker calls the API directly.
• Accepting a JWT 'because it's signed' without checking scopes/audience/expiry — a valid-but-sloppy token is a free pass.
• Using a weak password policy but no MFA — the cheap hard-policy is bypassed by breaches anyway.
• Mixing authN errors ('wrong password') with authZ ('not allowed') in one response, leaking account existence.

• 401 vs 403: 401 = authN failed (no/expired session); 403 = authN succeeded but authZ denied.
• A user 'can see things they shouldn't' almost always means an authZ check is missing or uses the wrong tenant id.
• Check token expiry and issuer claims first when sessions 'randomly' fail after a deploy.

• Phishing defeats password MFA-absent, and even OTP is phishable — hardware keys are strongest.
• AuthZ bugs (IDOR, path/object-level confusion) are heavily probed; enforce object-level checks, not just route-level.
• Session fixation and token leakage (in URLs, referrers, logs) are classic authN breaks to test for in your own apps.