Identity and Access Management

Security requires understanding the difference between two fundamental concepts: - Authentication (AuthN): "Who are you?" (Verifying identity via passwords, biometrics, or tokens). - Authorization (AuthZ): "What are you allowed to do?" (Checking roles and permissions).

Modern applications rely on several architectural patterns to handle these securely.

1. Session-Based Authentication (Stateful)

The traditional web approach. When a user logs in, the backend creates a session_id and stores it in a database or Redis cache. The server sends this ID back to the browser in an HttpOnly cookie. On every subsequent request, the browser sends the cookie. The server looks up the ID in the database to see who the user is. - Pros: Highly secure. You can instantly revoke a session by deleting it from the database. - Cons: Hard to scale. If you have 100 microservices, they all need to query the central session database constantly.

2. JWT - JSON Web Tokens (Stateless)

JWTs solve the microservice scaling problem. Upon login, the server cryptographically signs a JSON payload containing the user's ID and an expiration time. This token is sent to the client. On subsequent requests, the client sends the JWT (usually in an Authorization: Bearer <token> header). Any microservice can verify the cryptographic signature using a shared secret or public key, proving the token is valid without ever querying a database. - Pros: Massively scalable and decoupled. - Cons: You cannot easily revoke a JWT before it expires. If a hacker steals a JWT, they have access until it hits its expiration timestamp. (Often mitigated by using short-lived Access Tokens and long-lived Refresh Tokens).

3. OAuth 2.0 (Delegated Authorization)

OAuth is not an authentication protocol; it is a framework for delegated authorization. It allows an application to access data on another service without needing the user's password. Example: Granting a scheduling app access to your Google Calendar. You log into Google, Google asks if you want to grant permissions, and Google gives the scheduling app an Access Token. The app never sees your Google password.

4. OpenID Connect (OIDC)

OIDC is an authentication layer built on top of OAuth 2.0. This is the technology powering "Sign in with Google" or "Sign in with Apple." Instead of just getting an access token for an API, the application receives an id_token (a JWT) containing authenticated identity information (name, email, profile picture).

Multi-Factor Authentication (MFA)

Passwords are fundamentally weak due to human nature (reuse, phishing, weak entropy). MFA requires two or more evidence vectors: 1. Something you know: A password. 2. Something you have: A TOTP code from Google Authenticator, or a hardware YubiKey (FIDO2/WebAuthn). 3. Something you are: Fingerprint or FaceID. Hardware keys provide the absolute highest level of protection against phishing.

The Authorization Half: RBAC and Least Privilege

Authentication proves who you are; authorization decides what you may do, and it gets too little attention. The two workhorses are RBAC (Role-Based Access Control), where users belong to roles and roles carry permissions (sales_rep, admin, auditor), and ABAC (Attribute-Based Access Control), where decisions combine user attributes (department, region, clearance) with resource context and policy. The rule to enforce everywhere is least privilege: every token, service account, and role exists with the fewest permissions that still do the job. When you audit an API, the question is never just "are they logged in?" but "is this specific request authorized for this user against this object?" — broken object-level authorization is a top-real-world flaw, covered in the lesson on IDOR.

Token Lifecycle Discipline

Tokens are keys, and keys need a lifecycle. Issue short-lived access tokens (minutes to an hour) so a leak is a narrow window, issue longer refresh tokens that are rotated and revoked on re-issue, store tokens hashed (not plaintext) if you must store them server-side, and always set expiry — no token is "forever". On logout, revoke active sessions server-side, not just client-side. And never put a token in a URL: they already leak into server logs, referer headers, and browser history. Headers or signed, Secure, HttpOnly cookies are the only safe carriers.