Module 05 · Security · All tracks
Security & Auth
You don't need to be a security specialist — you need to never say something dangerous, and to show you build with threats in mind. This module gives you the defensible mental models.
By the end you'll be able to explain, with conviction:
- The difference between proving who you are and what you can do.
- How tokens, JWTs, and OAuth actually flow — and where they go wrong.
- The OWASP headline risks and how hashing differs from encryption.
1Authentication vs Authorization
Two words people blur constantly — and getting them straight is the bedrock of everything else.
Authentication (AuthN) answers "who are you?" — proving identity with credentials, a token, or a biometric. Authorization (AuthZ) answers "what are you allowed to do?" — checking permissions once identity is established. You authenticate first, then authorise. The airport analogy lands well: showing your passport is authentication; your boarding pass deciding which lounge you can enter is authorization.
Authorization itself comes in models: RBAC (role-based — permissions attached to roles like "admin") is the common default; ABAC (attribute-based) decides from attributes of the user, resource, and context for finer control. Naming RBAC vs ABAC signals you've thought past a single isAdmin flag.
Interview angle
"Authentication proves who you are; authorization decides what you can do — passport versus boarding pass. You always authenticate first, then authorise, usually with role- or attribute-based access control."
2Sessions vs tokens
Once a user authenticates, the server needs to remember them across requests — but HTTP is stateless (Module 04). Two strategies:
Session-based: the server creates a session, stores it server-side, and hands the client a session ID in a cookie. Every request sends the cookie; the server looks up the session. Simple and easy to revoke (delete the session) — but it's stateful, so it needs shared session storage to scale across many servers.
Token-based (typically JWT): the server issues a signed token the client stores and sends (usually in an Authorization: Bearer header). The server verifies the signature without any lookup — it's stateless, which scales beautifully and suits APIs and microservices. The cost is revocation: a valid token works until it expires, so you can't easily "log someone out" mid-life.
Interview angle
"Sessions are stateful and easy to revoke but need shared storage to scale; tokens are stateless and scale cleanly across services but are hard to revoke before expiry. I tune token lifetime short and pair it with refresh tokens to manage that tradeoff."
3JWT — structure & pitfalls
A JSON Web Token has three base64-encoded parts joined by dots: header (algorithm), payload (claims like user ID and expiry), and signature. The server signs the first two with a secret; on each request it recomputes the signature to verify the token is authentic and untampered.
alg, type] --> T["xxxxx.yyyyy.zzzzz"] P[Payload
claims] --> T S[Signature
HMAC/RSA] --> T
The critical pitfall: the payload is encoded, not encrypted — anyone can decode and read it. Never put secrets in a JWT. Other classics: the alg: none attack (reject it), overly long expiry (keep access tokens short-lived and use refresh tokens), and storing tokens in localStorage where XSS can steal them (an HttpOnly cookie is safer).
Common trap
Saying a JWT is "encrypted" is an instant red flag. It's signed — which guarantees integrity and authenticity, not confidentiality. The payload is readable by anyone who has the token.
4OAuth 2.0 & OIDC
OAuth 2.0 is an authorization framework for delegated access — it lets an app act on your behalf at another service without you handing over your password. "Log in with Google" and "let this app read your calendar" are OAuth. The key insight: it's about granting scoped, revocable access via tokens, not about proving identity.
OAuth alone doesn't tell the app who the user is — so OIDC (OpenID Connect) adds an identity layer on top, issuing an ID token (a JWT) with verified user info. The clean one-liner: OAuth is for authorization (access), OIDC adds authentication (identity).
Interview angle
"OAuth 2.0 delegates scoped access without sharing passwords — the app gets a token, not my credentials. OIDC sits on top to add identity via an ID token. So OAuth answers 'what can this app access,' OIDC answers 'who is the user.'"
5SSO & SAML
Single Sign-On lets a user authenticate once with a central identity provider and access many applications without logging in again. The win is both UX (one login) and security (centralised policy, MFA, and instant deprovisioning when someone leaves — disable one account, lose all access).
SAML is the older XML-based standard that powers a lot of enterprise SSO, exchanging signed assertions between an identity provider and service providers. In modern app-to-app and mobile contexts, OIDC (§4) is the lighter, JSON-based alternative increasingly preferred. You don't need SAML's internals — just know it's enterprise SSO, and OIDC is the modern counterpart.
6HTTPS / TLS in one breath
TLS (the protocol behind HTTPS) gives a connection three guarantees: encryption (eavesdroppers can't read it), integrity (it can't be tampered with in transit), and authentication (you're really talking to the site you think, via its certificate). The browser padlock means all three hold.
The mechanism in brief: a handshake uses asymmetric (public/private key) cryptography to verify the server's certificate and agree on a shared session key, then switches to fast symmetric encryption for the actual data. That hybrid — asymmetric to establish trust, symmetric for speed — is the one detail worth being able to sketch.
Interview angle
"TLS gives encryption, integrity, and server authentication. The handshake uses asymmetric crypto to validate the certificate and agree a shared key, then switches to symmetric encryption for speed — trust first, performance second."
7OWASP Top 10 — the headline risks
The OWASP Top 10 is the industry's consensus list of the most critical web vulnerabilities. You don't need all ten verbatim, but knowing the headliners signals security awareness:
- Broken Access Control — users doing things they shouldn't (the perennial #1).
- Injection — untrusted input executed as code/queries (SQLi, etc.).
- Cryptographic Failures — weak or missing encryption of sensitive data.
- Security Misconfiguration — default creds, verbose errors, open buckets.
- Vulnerable Components — outdated dependencies with known CVEs.
The unifying principle across the list is never trust input, and fail securely. Mentioning that you keep dependencies patched and validate everything at the boundary covers a surprising amount of it.
8SQLi · XSS · CSRF distinguished
These three get conflated; the distinction is what's being attacked.
- SQL Injection — attacker input is concatenated into a query and runs as SQL. Fix: parameterised queries / prepared statements, never string-building.
- XSS (Cross-Site Scripting) — attacker injects scripts that run in other users' browsers. Fix: escape/encode output, a Content Security Policy, and
HttpOnlycookies. - CSRF (Cross-Site Request Forgery) — a malicious site tricks a logged-in user's browser into making a state-changing request. Fix: anti-CSRF tokens and
SameSitecookies.
Common trap
The crisp distinction: XSS abuses the trust a user has in a site (runs scripts in their browser); CSRF abuses the trust a site has in the user's browser (rides their existing session). Stating it that way is a strong signal.
9Hashing vs encryption
A frequently-fumbled pair. Encryption is reversible — data is scrambled with a key and can be decrypted back. Use it for data you need to read later: messages, files at rest. Hashing is one-way — it produces a fixed fingerprint that can't be reversed. Use it for passwords: you store the hash and compare hashes, never the original.
For passwords specifically, a plain hash isn't enough — you add a salt (random per-password data) to defeat precomputed rainbow tables, and use a slow algorithm like bcrypt, scrypt, or Argon2 deliberately designed to be expensive, so brute-forcing is impractical. Saying "salted bcrypt, never MD5" instantly reads as competent.
Interview angle
"Encryption is reversible with a key, for data I need back; hashing is one-way, for passwords. I'd never store a password reversibly — I'd use a salted, slow hash like bcrypt or Argon2 so even a breached database is expensive to crack."
10Secrets management & compliance
Secrets — API keys, DB passwords, signing keys — must never live in source code or be committed to Git. The mature approach is a dedicated secrets manager (HashiCorp Vault, AWS Secrets Manager) that stores them encrypted, injects them at runtime, controls access, and supports rotation. "Secrets out of the repo, injected at runtime, rotated regularly" is the answer.
On compliance, awareness is enough unless the role is specialised. GDPR — EU data privacy (consent, right to deletion). HIPAA — US healthcare data protection. SOC 2 — an audited report on a company's security controls. You won't be quizzed on legal detail; you're expected to know these shape how you handle personal and sensitive data, and to design with data minimisation and least privilege in mind.
Go deeper
Two principles tie this whole module together: least privilege (grant the minimum access needed) and defense in depth (layer controls so one failure isn't fatal). If you anchor security answers to those two, you'll sound principled rather than checklist-driven.
Recap — what you can now teach
- AuthN proves identity, AuthZ grants permissions — authenticate first, then authorise.
- Sessions are stateful/revocable; tokens are stateless/scalable but hard to revoke before expiry.
- A JWT is signed, not encrypted — never put secrets in the payload.
- OAuth delegates access; OIDC adds identity on top.
- TLS = encryption + integrity + authentication via an asymmetric handshake, then symmetric speed.
- Know SQLi/XSS/CSRF and their fixes; hash passwords with salted bcrypt/Argon2, never store reversibly.
- Secrets out of the repo; anchor everything to least privilege and defense in depth.
Self-check
Say each answer out loud before revealing it.
Is a JWT encrypted? What does its signature guarantee?
No — the payload is only encoded and readable by anyone. The signature guarantees integrity and authenticity (it wasn't tampered with and came from the issuer), not confidentiality.
OAuth vs OIDC in one line each?
OAuth = delegated authorization (scoped access via tokens, no password sharing). OIDC = an identity layer on OAuth that proves who the user is via an ID token.
How do you store passwords safely?
Hash them (one-way) with a unique salt using a slow algorithm like bcrypt, scrypt, or Argon2 — never encrypt or store them in plaintext.
XSS vs CSRF — what trust does each abuse?
XSS abuses the user's trust in a site (runs malicious scripts in their browser); CSRF abuses the site's trust in the user's browser (rides their existing session to make requests).
What's the tradeoff between session and token auth?
Sessions are stateful — easy to revoke but need shared storage to scale. Tokens are stateless — scale cleanly but can't easily be revoked before they expire.