Chapter 5 — Authentication Basics

The why

Auth is where most products get hacked. Not from clever attacks — from boring mistakes. Get the basics right and you'll never appear on Have-I-Been-Pwned.

Authentication vs Authorization

These two words look alike. They are not.

• Authentication (authn) — who are you? Verifying identity. Username + password, OAuth, biometrics.
• Authorization (authz) — what may you do? Verifying permission. RBAC, ABAC, scopes.

Most "auth bugs" are actually authz bugs. The user is who they say they are — they just shouldn't be able to do that. We'll spend much of L3 on authz.

This chapter is about authn.

Two mental models: sessions and tokens

There are exactly two ways to remember a logged-in user across requests. Everything else is a variant.

Model 1 — Sessions (cookie-based)

1. User logs in. Server creates a random session ID (e.g., abc123...) and stores it in a database / Redis with the user's ID.
2. Server sends Set-Cookie: session_id=abc123; HttpOnly; Secure; SameSite=Lax.
3. Browser stores the cookie. Sends it automatically on every request to that domain.
4. Server looks up abc123 → finds user 42 → authenticated.

Good. Easy to revoke (delete from store). Secrets stay server-side. Battle-tested.

Bad. Requires a shared session store across all your servers. Harder for mobile/native (no automatic cookies).

Model 2 — Tokens (typically JWT)

1. User logs in. Server creates a signed token containing user info: {"sub": 42, "exp": ...}.
2. Server returns the token in the response body or a cookie.
3. Client stores the token (memory, cookie, or — careful! — localStorage).
4. Client sends Authorization: Bearer <token> on each request.
5. Server verifies the signature and extracts the user info. No DB lookup needed.

Good. Stateless — any server can verify. Works easily for mobile and service-to-service.

Bad. Hard to revoke before expiry (need a denylist, defeating the point). Tokens leak via XSS, logs, third-party scripts.

Which to use?

• Browser-only SaaS, single backend? Sessions. The simpler thing wins.
• Mobile app or service-to-service? Tokens.
• Microservices? Tokens at the edge, optional sessions within.

Most products end up doing both: short-lived access token (JWT) + long-lived refresh token (session-backed). We'll build this in L3.

Anatomy of a JWT

A JWT is three base64url-encoded chunks separated by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiI0MiIsImV4cCI6MTk5OTk5OTk5OX0.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decoded:

{ "alg": "HS256", "typ": "JWT" }

{ "sub": "42", "exp": 1999999999 }

Signature: HMAC-SHA256(header.payload, secret)

Critical things to know:

• The payload is NOT encrypted, only signed. Anyone can read it. Never put a password in there.
• The signature is what makes it trustworthy. Change one byte of the payload and the signature breaks.
• alg: none is a real, dangerous attack. Always specify the expected algorithm when verifying.

$ echo "eyJzdWIiOiI0MiJ9" | base64 -d
{"sub":"42"}

That's how easy it is to read a JWT. Treat the payload as public information that's also tamper-evident.

Password authentication, briefly

We'll go deep in L3. The basics here:

1. Never store plaintext passwords. Ever.
2. Never hash with MD5 or SHA1. They're for file checksums, not passwords.
3. Use bcrypt or argon2. These are slow on purpose — that's the feature.
4. Salt automatically (bcrypt does this; argon2 does this).
5. Hash on the server, never the client. Pre-hashed passwords are just plaintext passwords with extra steps.

import bcrypt from 'bcrypt';
 
// On signup
const hash = await bcrypt.hash(password, 12);  // cost 12 = ~250ms on modern hardware
await db.users.create({ email

OAuth — "Sign in with Google"

You won't always do auth yourself. OAuth lets Google, GitHub, Apple, etc. authenticate the user for you.

We'll wire this up in L3. For now know it exists, that you should never roll OAuth yourself (use a library), and that PKCE is mandatory for any client you don't control.

Common mistakes (the three classics)

Production · Performance · Security notes

Production. Log every auth event (login, logout, password change). Monitor failure rates — a spike means a credential stuffing attack.

Performance. Sessions backed by Redis are fast. Don't put session lookups behind your slow primary DB.

Security. Set cookies with HttpOnly; Secure; SameSite=Lax by default. Make exceptions only when you know why.

Exercises

1. Beginner. Open https://jwt.io. Paste any sample JWT and decode it.
2. Beginner. Inspect a logged-in session on a site you use. Find the session cookie. Note HttpOnly, Secure, SameSite.
3. Intermediate. Write a 10-line script that bcrypts a password and verifies it.
4. Advanced. Forge a JWT (locally — on a server you own) by changing sub and re-signing with your own secret. Verify the change works.

Interview questions

Beginner. What's the difference between authentication and authorization? Authn = who you are. Authz = what you may do.

Senior. How do you revoke a JWT? You can't, by design. Workarounds: short TTL + refresh tokens; or keep a denylist (which defeats statelessness); or pair JWT with a session for sensitive ops.

Summary

Authentication is "who are you?" Two mechanisms dominate: sessions (cookies + server store) and tokens (JWT + signature). Sessions are simpler and easier to revoke; tokens are stateless and scale better. Either way: hash passwords with bcrypt/argon2, set cookies correctly, and never trust the client.

Quick recall

• Authn = identity. Authz = permission.
• Sessions = simple, revocable, needs shared store.
• Tokens (JWT) = stateless, hard to revoke, leaks if mishandled.
• JWT payload is NOT encrypted — only signed.
• Hash passwords with bcrypt or argon2, on the server.

Quiz

1. Why is hashing a password on the client useless?
2. What does HttpOnly on a cookie prevent?
3. What's the difference between an access token and a refresh token?
4. Can a JWT be revoked easily? Why or why not?
5. What's the alg: none attack?