Authentication Systems
Deep Dive

01 — Authentication vs Authorization

Authentication (AuthN) answers "who are you?" It verifies identity — checking a password, validating an OAuth token, or confirming a magic link. The output is a verified identity: "this is user #42."

Authorization (AuthZ) answers "what can you do?" Given a verified identity, it checks permissions — can user #42 edit this document? Access the admin panel? Delete this record?

In practice, most "auth systems" blend both. A JWT might carry both identity (sub: "user_42") and permissions (role: "admin"). But conceptually, they are distinct concerns that happen to travel together.

02 — The Token Lifecycle

Every auth system follows the same fundamental loop: prove identity once, then carry proof on every subsequent request. The "proof" is a token. Here's what happens from login to logout:

Cookie Mechanics

Tokens travel via cookies. Four flags control their security:

Set-Cookie: access_token=eyJhbGci...;
  HttpOnly;
  Secure;
  SameSite=Lax;
  Path=/;
  Max-Age=900

03 — Access Tokens vs Refresh Tokens

The single most common question: why two tokens instead of one?

The Real Reason for Two Tokens

It comes down to one tradeoff: how often do you hit the database?

• Access token (15 min): Stateless. The server validates the cryptographic signature without touching the database. Fast. Used on every single API call. But it cannot be revoked — it's valid until it expires.
• Refresh token (7–30 days): Stateful. Stored (as a hash) in the database. Only used when the access token expires (~every 15 min). The server checks the DB, confirms it hasn't been revoked, and issues a new access token.

This means 99% of requests never touch the session database, but you can still revoke access within 15 minutes by deleting the refresh token. The access token will naturally expire, and when the client tries to refresh, it gets rejected.

04 — JWT Deep Dive

A JSON Web Token is three Base64URL-encoded segments separated by dots. Nothing is encrypted — anyone can read the payload. The signature just proves it hasn't been tampered with.

Signing: HMAC vs RSA

Why JWTs Are Stateless

The server doesn't store JWTs anywhere. All the information needed to validate one (the signing secret, the algorithm) is already on the server. This means:

• No database lookup per request — just verify the signature and check exp
• Horizontally scalable — any server can validate any token
• But: no revocation — you can't "invalidate" a JWT before it expires without adding statefulness (a blocklist)

Common JWT Pitfalls

05 — Opaque Tokens & Server-Side Sessions

The opposite of JWTs. An opaque token is a random string with no readable content. All session state lives in the database. The token is just a lookup key.

Opaque vs JWT Comparison

TTL Indexes for Cleanup

In MongoDB, create a TTL index on the expiresAt field. MongoDB automatically deletes expired documents within ~60 seconds of their expiry time:

db.sessions.createIndex(
  { expiresAt: 1 },
  { expireAfterSeconds: 0 }
)

This eliminates the need for a cron job or manual cleanup. Expired sessions vanish automatically.

06 — Session Management Patterns

Sliding Window vs Fixed Expiry

Session Fixation

The attack: Attacker creates a session, tricks the victim into using that session ID (via a crafted link), then hijacks the session after the victim logs in.

The fix: Always regenerate the session ID after authentication. The old session ID (potentially known to the attacker) becomes useless. The newly authenticated session gets a fresh, unknown ID.

// After successful login:
const oldSessionId = req.cookies.session;
await sessions.delete(oldSessionId);  // kill old session

const newToken = crypto.randomBytes(32);  // fresh token
await sessions.create(newToken, userId);  // new session
res.cookie("session", newToken);          // replace cookie

Concurrent Session Limits

Decide your policy: how many active sessions per user?

• Unlimited: User can be logged in on phone, laptop, tablet simultaneously. Simplest.
• Limited (e.g., 5): When creating session #6, revoke the oldest. Prevents credential sharing.
• Single session: New login kills all other sessions. Maximum security, worst UX.

Device-Aware Sessions

Store metadata alongside the session hash: user agent, IP, last active timestamp, device fingerprint. This enables:

• "You're logged in on 3 devices" UI (like Google's security page)
• Selective revocation: "Log out of my work computer"
• Anomaly detection: session suddenly used from a different country

07 — The Refresh Flow in Detail

Token Families and Replay Detection

Every refresh token belongs to a family (typically identified by the original session ID). When the server sees a refresh token that has already been used:

1. It knows the token was stolen (either the attacker or the legitimate user has the old one)
2. It revokes all tokens in that family — both the legitimate and stolen branches
3. Both parties must re-authenticate

This is the "nuclear option" — but it's the only safe response because the server can't tell which party is legitimate.

The Race Condition Problem

08 — OAuth 2.0 & OpenID Connect

OAuth 2.0 is a delegation framework. It lets a third-party app access a user's data without seeing their password. OpenID Connect (OIDC) adds an identity layer on top.

ID Token vs Access Token (OIDC)

09 — Attack Vectors & Defenses

Token Storage: Where Should Tokens Live?

10 — Build vs Buy

Solutions Compared

What Each Solution Handles For You

Key Takeaways

1. Two tokens solve a real tradeoff: access tokens are a stateless cache of authorization (fast, not revocable); refresh tokens are the real session (slow, revocable). Together they give you speed without sacrificing revocation.
2. HttpOnly cookies, always. Never store tokens in localStorage. One XSS and you're compromised.
3. Refresh token rotation is non-negotiable. Each refresh should issue a new pair and invalidate the old. Replay detection via token families catches stolen tokens.
4. JWTs are not sessions. They're signed data packets. Great for stateless access tokens, but if you need revocation, you need server-side state (opaque tokens or a JWT blocklist).
5. Hash before store. Never store raw tokens in the database. SHA-256 hash them. If your DB is breached, attackers get useless hashes.
6. PKCE is mandatory for public clients. Any OAuth flow from a browser or mobile app must use PKCE to prevent authorization code interception.
7. For a small team: use Auth.js or Clerk. Custom auth is a 10,000-line commitment with ongoing security maintenance. The ROI rarely makes sense under 10 engineers.