Chapter 2: The mental model - authentication, authorization, and identity

Most auth confusion comes from conflating three things that are related but distinct. A developer implementing login for the first time thinks about “auth” as a single problem. It is not. Authentication proves who you are. Authorization determines what you can do. Identity management governs the lifecycle of the user record across both. Mix them up and you design systems that fail in predictable ways: a session check that authorizes instead of authenticates, a JWT that carries roles it should not, a user record that cannot be deleted because authorization data is tangled into it.

This chapter builds the conceptual foundation. No code yet. Every chapter after this one assumes you have these distinctions clear.

After this chapter you will be able to

• Distinguish authentication, authorization, and identity management as separate concerns with separate failure modes
• Choose between stateful and stateless authentication for a given architecture
• Understand the identity lifecycle from registration through deprovisioning
• Map a user’s journey through a platform to the auth decisions at each step
• Recognize the tradeoffs between building auth in-house and outsourcing to a provider

Why this matters

If you do not know which problem you are solving, you cannot evaluate solutions. A team that says “we need auth” might mean they need a login form (authentication), might mean they need to control which users can delete records (authorization), or might mean they need to sync user accounts with their customer’s corporate directory (identity management). The same provider might handle all three, or you might compose separate tools. The decision depends on understanding the boundaries.

The three pillars

Authentication: who are you?

Authentication answers one question: is this person who they claim to be? The answer is binary - yes or no. The mechanism is verification against something the user knows (password, PIN), has (security key, phone), or is (fingerprint, face). Multi-factor authentication combines two or more of these categories.

A successful authentication produces a session or a token that the user presents on subsequent requests. The important architectural point: authentication is an event (it happens once at login) but its result persists (the session or token). Chapter 3 covers local password-based authentication. Chapter 5 covers delegated authentication via OIDC.

Authentication failure modes are clear: someone who should not gain access does, or someone who should gain access cannot. The first is a security problem. The second is an availability problem. Both are bad for a platform.

Authorization: what can you do?

Authorization answers a different question: given that we know who you are, should you be allowed to perform this action on this resource? The answer is contextual: it depends on the user’s role, the resource’s ownership, the action being attempted, and sometimes the environment (time of day, IP range, device posture).

Authorization happens on every request, not just at login. A user who authenticated hours ago may no longer be authorized for an action because their role changed, their subscription expired, or they were removed from a project. The system that checks authentication once and never re-checks authorization is the system that lets a fired employee still access the admin panel because their session has not expired yet.

Authorization models are covered in depth in Chapter 10 (Available in full handbook). Session-bound authorization patterns appear in Chapter 4 (Available in full handbook).

These three pillars form a stack, each depending on the one below:

Identity management: the full lifecycle

Identity management governs the user record across its entire existence: registration, profile management, credential changes, role changes, and eventual deprovisioning. It is the administrative layer that connects authentication and authorization.

A user is not just a row in a users table. A user is a collection of identities (email/password, Google OAuth, SAML from their employer), a set of credentials (password hash, TOTP secret, WebAuthn public key), a set of group and role memberships, and a history of actions (audit log). When a user asks to delete their account, identity management must cascade across all of these - revoking sessions, removing role assignments, and retaining the audit trail for compliance while removing personally identifiable information.

Enterprise identity management adds federation and provisioning. When a company onboards 500 employees to your platform, they do not want to create 500 accounts manually. They want SCIM provisioning (Chapter 8) to sync users from their directory. When an employee leaves the company, your platform must receive a deprovisioning event and revoke access within the SLA the enterprise contract specifies.

Stateful vs stateless authentication

A fundamental architectural choice that shapes the rest of your auth system.

Stateful authentication stores a session record on the server. The client holds a session identifier (usually a cookie), and the server looks up the session on each request. The session record contains the user’s identity, plus optionally their roles, permissions, and metadata. Revocation is instant: delete the session record. Scaling requires a shared session store (Redis, database). This is the traditional web application model.

Stateless authentication encodes the user’s identity and claims into a self-contained token (usually a JWT). The client holds the token and sends it with each request. The server validates the token’s signature and expiration but does not need to look up session state. Revocation is hard: you cannot delete a JWT that has already been issued. The typical mitigation is short token lifetimes (5-15 minutes) with a refresh mechanism. This model works well for APIs and microservices where a session store would create a bottleneck.

You might expect stateless to be simpler. It is not. The revocation problem alone creates enough edge cases that most platforms end up with a hybrid: short-lived access tokens (stateless) plus long-lived refresh tokens tracked server-side (stateful). Chapter 4 covers session management in depth, with patterns for both models.

The identity taxonomy

Not every auth approach fits every platform. Here is a framework for matching auth architecture to platform stage:

The transitions between stages are where platforms bleed. Moving from “basic email/password” to “enterprise SSO” is a migration, not a feature toggle. Chapter 13 covers how to plan these transitions before they become emergencies.

Build vs buy: the auth decision

Every platform faces the same question: should we build auth ourselves or use a service? The answer is never pure build or pure buy. Even with a provider, you still own session management in your application, role-to-permission mapping, and the integration between the provider’s user record and your application’s data model. You are always building something.

The question is really about which parts to build and which to buy.

Build when: - Your auth requirements are simple and will stay simple (a handful of user types, no federation) - You need deep integration between identity and your domain model that a provider’s user object cannot express - You operate in a regulated industry where externalizing identity to a SaaS creates compliance risk - You have the engineering bandwidth to maintain auth infrastructure as a core competency, not a side task

Buy when: - You need compliance certifications (SOC 2, ISO 27001) and the provider brings them - You need enterprise SSO and the provider handles SAML/OIDC federation so you do not have to implement it yourself - Your team is small and auth is not your product’s differentiator - You are willing to accept vendor lock-in in exchange for faster time to market

The middle ground is open-source self-hosting (Chapter 7): you own the deployment, the provider owns the feature set, and you can fork if necessary. Keycloak, Zitadel, and Ory all offer this path.

The mistake to avoid is assuming the buy decision is permanent. Auth0 customers have migrated to Keycloak when costs grew. Firebase Auth users have migrated to Supabase when they needed more control. Clerk users have migrated to WorkOS when enterprise SSO requirements surfaced. Every buy decision should include a migration path, even if you never use it. Chapter 13 covers this in detail.

Key takeaways

• Authentication (who you are), authorization (what you can do), and identity management (lifecycle of the user record) are separate concerns. Conflating them leads to systems that are hard to change and hard to secure.
• Stateful sessions give you instant revocation but require shared storage. Stateless JWTs give you scalability but make revocation difficult. Most platforms end up with a hybrid.
• The auth architecture that fits a prototype will not fit a multi-tenant SaaS. Plan for transitions before they become migrations.
• Build vs buy is not a binary. Every platform builds some parts and buys others. Know which parts you are building, which you are buying, and what your migration path is.

Further reading

• Google Zanzibar paper - the paper that defined ReBAC at web scale. Foundation for understanding modern authorization models (Chapter 10)
• OWASP Session Management Cheat Sheet - the definitive reference for session security (Chapter 4)
• RFC 9700 - OAuth 2.0 Best Current Practice - the January 2025 update that deprecated the implicit grant and password grant (Chapter 5)
• NIST SP 800-162 - Attribute-Based Access Control - the ABAC reference architecture (Chapter 10)

Common pitfalls

• Using JWT as a session token for web applications. JWTs are for API authorization between services, not for browser session management. A cookie with an opaque session ID is simpler, more secure, and instantly revocable. A JWT in the browser requires you to solve revocation, token storage, and XSS protection simultaneously. Use the BFF pattern (Chapter 11) instead.
• Baking roles into the JWT and not re-checking authorization on the server. If role claims are in a JWT issued at login, and the user’s role changes five minutes later, the JWT still says the old role until it expires. Always re-check authorization on the backend for sensitive operations.
• Assuming your auth provider handles everything. A provider gives you a user object and session management. It does not give you authorization logic, audit trails, or the integration between the provider’s user and your domain objects. You still have to build those.

Checkpoint exercise

For your current platform (or the one you plan to build), answer these four questions:

1. Which authN mechanism are you using? (passwords, social login, SAML, multiple?)
2. How do you authorize requests? (a single role column, middleware, an external policy engine?)
3. How do you manage the identity lifecycle? (what happens when a user changes their email, loses their 2FA device, or requests account deletion?)
4. What would break if your auth provider disappeared tomorrow? (be specific - list every system that depends on their user IDs, tokens, or webhooks)

Save your answers. Return to them after Chapter 13. What changed?