Authentication & Access Control
Authentication and access control answer three different questions: who you are (identification), whether that is true (authentication), and what you may do (authorization). They must not be mixed — most access flaws are born precisely from substituting one for another. On top of this foundation sits a practical layer: how a JWT is built, where to store it, what its pitfalls are, and how to defend login and account-recovery flows.
The traps here are expensive. A JWT is signed but not encrypted — its payload is readable, so secrets in it leak; localStorage is reachable by any script, so one XSS steals the token; alg=none makes the server accept an unsigned token; and different responses for a wrong username versus a wrong password enable user enumeration. Each mechanism and its defense is in the layers below.
Topic map
- Identification, authentication, authorization — three distinct steps, their order, and why they must not be confused.
- JWT structure — the three parts
header.payload.signatureand why a signature is not encryption. - JWT client storage —
localStoragevs anhttpOnlycookie vs memory and the risk of each. - JWT vulnerabilities —
alg=none,HS/RSconfusion, weak secret, missingexp,kidinjection. - Defending login against attacks — detecting and preventing brute-force, stuffing, spraying, enumeration and session hijacking.
- SMS-bombing defense — why the problem is the send cost, not guessing the code.
- Password-recovery audit — predictable links, host header injection, TTL and OTP limits.
Common traps
| Mistake | Consequence |
|---|---|
| Confusing authentication (proof) with authorization (rights) | A wrong access model: you check the wrong thing in the wrong place |
Treating a JWT payload as encrypted and putting secrets in it | The payload is readable by anyone — secrets leak |
Storing a JWT in localStorage | One XSS steals the token: localStorage is reachable by any script |
Not rejecting alg=none on the server | The server accepts an unsigned token — authentication bypass |
| Returning different responses for "no such user" and "wrong password" | User enumeration |
Building a recovery link from the Host header | Host header injection — an attacker forges the link domain |
Leaving the OTP send endpoint open to anonymous users | SMS bombing burns budget on the send |
Interview relevance
The topic checks whether you separate the access layers and understand what each mechanism actually protects. A candidate who says "a JWT is signed, not encrypted; localStorage is stolen by XSS; authorization is checked on every request" immediately separates from one who memorized the words.
Typical checks:
- The difference between identification, authentication and authorization, and their order.
- What a
JWTconsists of, why the payload is readable, and where to safely store it. - Typical
JWTvulnerabilities and how to close them (alg,exp, keys,kid). - How to detect and prevent credential stuffing, spraying, brute-force and session hijacking.
- Which flaws to look for in a password-recovery flow and in
OTP-abuse defense.
Common wrong answer: "a JWT is encrypted, so you can store anything in the payload, and localStorage is safe because the token cannot be read without the server key". In fact an ordinary JWT is only signed, the payload is readable by base64url decoding, and a token in localStorage is read by any script on the page.