Auth architecture that actually scales.

By Joseph Alexander

Most auth systems break at scale because they were bolted on as an afterthought. Here's how to design identity and access management that grows with your product.

Auth is infrastructure, not a feature

Authentication and authorization touch every part of your application. Yet most teams treat auth as a checkbox feature — bolt on a JWT library, add a login page, and move on. This works until it doesn't, and when auth breaks at scale, everything breaks.

Common auth mistakes that haunt you later

  • Rolling your own auth: Custom password hashing, homegrown session management, DIY token rotation. Every one of these is a security incident waiting to happen. Use battle-tested libraries and providers.

  • Session management anti-patterns: Storing sessions in local memory (breaks with multiple servers), never rotating tokens, missing refresh token flows, or storing sensitive data in JWTs.

  • No separation of authentication and authorization: Knowing who someone is (authentication) and what they can do (authorization) are different concerns. Mixing them creates unmaintainable permission spaghetti.

Choosing the right identity provider

The three main paths each serve different needs:

  • Keycloak: Open-source, self-hosted, maximum control. Ideal for enterprises with compliance requirements or teams that need full customization. Steep learning curve but unmatched flexibility.

  • Auth0: Managed service, fast integration, excellent developer experience. Best for startups that want auth solved quickly without managing infrastructure. Gets expensive at scale.

  • Custom on proven libraries: Passport.js, NextAuth, or Lucia built on your own database. Right for simple apps with straightforward auth needs. Wrong for anything with complex roles or multi-tenancy.

Token management done right

A robust token strategy includes:

  • Short-lived access tokens (15 minutes max)

  • Secure refresh token rotation with reuse detection

  • Token revocation lists for immediate access removal

  • Audience and scope restrictions on every token

  • HttpOnly, Secure, SameSite cookies for web applications

RBAC vs ABAC: choosing your permission model

Role-Based Access Control (RBAC) assigns permissions to roles, then roles to users. Simple, auditable, and sufficient for most applications. Start here.

Attribute-Based Access Control (ABAC) evaluates policies based on user attributes, resource attributes, and environment conditions. Necessary when permissions depend on data relationships ("users can only edit their own department's records").

Migration strategies

If you're migrating from a broken auth system, run both systems in parallel. Route new signups to the new system, migrate existing users in batches with hash-compatible password migration, and use feature flags to gradually shift traffic. Never do a big-bang auth migration — the blast radius is your entire user base.

Follow me to keep in touch

Where I share my creative journey, design experiments, and industry thoughts.