Authentication and authorization
Who are you, and what are you allowed to do — two different questions.
- Distinguish authentication from authorization
- Explain how passwords should be stored
- Describe sessions and tokens at a high level
Two words that sound alike and are constantly confused, but answer different questions:
- Authentication (authn): who are you? Proving identity.
- Authorization (authz): what are you allowed to do? Granting access.
You authenticate once ("this is Ada"), then authorize many times ("can Ada delete this record?"). Mixing them up — or skipping the second — is a classic source of breaches.
Storing passwords (the right way)
If you remember one security fact, make it this: never store passwords in plain text, and never encrypt them — hash them.
- A hash is a one-way function: easy to compute, infeasible to reverse. You store the hash; at login you hash the attempt and compare.
- Use a slow, salted password hash designed for the job — bcrypt, scrypt, or Argon2 — never a fast general hash like MD5 or SHA-256 alone.
- A salt (random per-user value mixed in) ensures two users with the same password get different hashes, defeating precomputed-table attacks.
This way, even if your database leaks, the passwords aren't directly recoverable.
Sessions and tokens
After authentication, the server needs to remember you across requests (HTTP itself is stateless). Two common approaches:
- Sessions: the server stores session state and gives the browser a session ID (usually in a cookie). The server looks you up each request.
- Tokens (e.g. JWT): the server issues a signed token the client sends back; the signature proves it's valid without a server-side lookup.
Either way, the secret material must travel over HTTPS and live in secure,
HttpOnly cookies or equivalent — never in places hostile scripts can read.
Authorize every action
Authentication without authorization is a wide-open door. Check permissions on every protected action on the server — never trust the client to enforce it (hiding a button isn't security). The least-privilege principle applies: grant the narrowest access that works.
A frequent real-world bug: checking that a user is logged in but not that the record they're touching is theirs. Always authorize the specific action on the specific resource, server-side.
Where to go next
Credentials and keys are themselves a prime target. Next: secrets and dependencies.