Chapter 1 — Authentication vs Authorization

The why

Authentication and Authorization are two different problems that most beginners (and a shocking number of production systems) confuse. Mix them up and you ship a CVE. This chapter draws the line — permanently.

Core concepts

The one-sentence definitions

• Authentication (AuthN): Verifying who you are. "Prove you're Alice." Done via passwords, tokens, biometrics, OAuth.
• Authorization (AuthZ): Determining what you can do. "Alice can read documents but not delete them." Done via roles, permissions, policies.

The three authorization models

// RBAC — simplest, most common
function canDeletePost(user: User, post: Post): boolean {
  if (user.role === 'admin') return true;
  if (user.role

The auth boundary on a system diagram

Every backend request passes through an auth layer. Here's where AuthN and AuthZ live:

Request → [TLS] → [Rate Limiter] → [AuthN Middleware: "Who are you?"]
  → [AuthZ Middleware: "Are you allowed?"] → [Controller/Handler] → [Response]

• AuthN middleware extracts the token/session, validates it, and attaches the user to the request (req.user = { id, email, role }).
• AuthZ middleware checks if req.user has permission for this specific action on this specific resource. This is where RBAC/ABAC/ReBAC lives.

Common auth bug identification

Given a bug, can you identify whether it's an AuthN or AuthZ problem?

Real-world example: How Slack handles auth

Slack uses a sophisticated multi-model auth system:

1. AuthN — Email + password, SSO (SAML/OIDC), or magic link. Authenticated via session cookie or token.
2. AuthZ — ReBAC at the core. "Can Alice see this message?" depends on: is Alice a member of the channel? Is the channel public or private? Was Alice invited? Is Alice a guest with restricted channel access?
3. Scopes for API tokens. Bot tokens and user tokens have granular scopes: channels:read, chat:write, users:read. This is ABAC applied to API access.

Slack's lesson: auth scale isn't about performance — it's about policy complexity. When permissions depend on team membership, channel type, user role, AND guest restrictions, RBAC alone isn't enough. ReBAC models the relationship graph naturally.

Common mistakes

Production notes

• Centralize authorization logic. One module (authz.ts or permissions.ts) that exports functions like can(user, action, resource). Every endpoint calls this. Audit once, fix everywhere.
• Log auth failures. Every 401 and 403 should be logged with user ID, attempted action, and resource. This is how you detect attacks.
• Rate limit auth endpoints. Login, password reset, token refresh — these are targets for brute force and credential stuffing.

Performance notes

• Auth checks must be fast. A permission check that takes 50ms adds 50ms to every request. Cache roles/permissions in Redis or in the token itself (JWT claims).
• JWT vs DB lookup for every request. JWT lets you verify identity without a database query (~0.1ms). But revocation requires a blocklist. Sessions require a DB/Redis lookup (~1ms) but support instant revocation. Tradeoff.

Security notes

• Fail closed, not open. If the auth service is unreachable, deny access (500 or 503), don't allow it. "Default deny" is a security principle, not a preference.
• Don't leak existence. A 403 "user not found" vs 403 "insufficient permissions" — the former confirms the user exists (user enumeration). Return the same error for both: "Not found or not authorized."

Exercises

Beginner

1. Write an Express middleware that checks if a user is authenticated (has a valid JWT in the Authorization header). Return 401 if not. Attach req.user.
2. Write a second middleware that checks authorization: only users with role === 'admin' can access the route. Return 403 if not.

Intermediate

1. Build an RBAC system with three roles: admin, editor, viewer. Implement can(user, action, resource) where action is create, read, update, delete and resource is post. Write tests for each role-action combination.
2. Implement resource ownership checks: only the post author or an admin can update/delete a post. Write middleware that loads the post and checks ownership.

Advanced

1. Design an ABAC system where documents have department and classification attributes and users have department, clearanceLevel, and role attributes. Implement a policy engine that evaluates rules like "editors can read documents in their department, but only if their clearance level >= the document's classification."
2. Research Google Zanzibar (the paper). Implement a basic ReBAC system with a relationship graph. Support checks like "is user X a member of team Y?" where teams can be nested.

Interview questions

Beginner

1. What's the difference between authentication and authorization? Authentication verifies identity ("who are you?"). Authorization determines permissions ("what can you do?"). You can be authenticated without being authorized, but typically not authorized without being authenticated.

2. What status code should you return for a missing auth token vs insufficient permissions? 401 for missing/invalid auth (unauthenticated). 403 for valid auth but insufficient permissions (unauthorized).

3. What is RBAC? Role-Based Access Control. Users are assigned roles, roles are assigned permissions. Simplest and most common authorization model.

Senior

4. When would you choose ABAC over RBAC? When permissions depend on attributes of the user, resource, AND environment, not just role. Example: "Doctors can view patient records only for patients in their own department, only during their shift hours, and only if the patient hasn't opted out of data sharing." RBAC can't express this without an explosion of roles.

5. Explain IDOR and how to prevent it. Insecure Direct Object Reference — an attacker changes a resource ID in the URL (/orders/12345 → /orders/12346) and accesses another user's data because the backend doesn't check ownership. Prevent by: always verifying that the authenticated user owns or is authorized for the requested resource. Never rely on sequential/hidden IDs alone.

6. How would you design an authorization system that survives 5 years of product changes? Use a centralized policy evaluation function (can(user, action, resource)). Store roles/permissions in the database, not hardcoded in code. Support attribute-based policies from day one (even if initially only RBAC). Log every authorization decision for audit. Make the system testable in isolation. The key insight: separate the policy evaluation from the business logic so policies can evolve independently.

Summary

Authentication = identity. Authorization = permissions. They are different problems that require different middleware, different error codes (401 vs 403), and different testing strategies. RBAC covers 90% of applications. ABAC handles attribute-driven policies. ReBAC handles relationship-based access (social graphs, team structures). Auth checks must be centralized, fast, and auditable. Never implement auth from scratch. Fail closed.

Quick recall

• AuthN = "Who are you?" (401). AuthZ = "What can you do?" (403).
• RBAC: roles → permissions. ABAC: attributes → policies. ReBAC: relationships → access.
• Centralize auth logic. Check on the backend. Check resource ownership.
• Fail closed (deny by default). Log all 401/403s. Rate limit auth endpoints.
• Use established libraries (Passport, NextAuth, Supabase Auth). Never roll your own crypto.

Quiz

1. What status code means "I don't know who you are"? 401 Unauthorized (despite the name, it means unauthenticated).
2. What status code means "I know who you are, but you can't do that"? 403 Forbidden.
3. Which auth model is simplest for most applications? RBAC (Role-Based Access Control).
4. What does IDOR stand for and how do you prevent it? Insecure Direct Object Reference. Prevent by checking resource ownership on every request.
5. Why should you centralize authorization logic? So permissions are defined in one place, audited once, and consistently enforced everywhere.
6. What does "fail closed" mean in the context of auth? If the auth service is unavailable, deny access rather than allowing it.
7. Name three things you should never implement from scratch. Authentication, password hashing, session management, encryption. Use established libraries.