Deepak Gupta

The Reference Architecture

A production identity platform is a set of small, stateless services in front of a few carefully guarded data stores. Keep the services stateless and the data regional, and almost every scaling and compliance problem later gets easier.

  Clients: web, mobile, partner apps, CLIs, AI agents
                        |
                        v
  Edge: TLS, WAF, bot scoring, coarse rate limits
                        |
                        v
  Identity layer (stateless services)
    Login API + UI | OAuth/OIDC server | Federation (SAML, social)
    MFA + WebAuthn | Risk engine       | Admin, SCIM, events
                        |
                        v
  Data (per region)
    User store | Session cache | Key management (KMS/HSM) | Audit log

Read it top to bottom. Clients never talk to data stores directly. Every request crosses the edge, then exactly one identity layer, and only that layer touches users, sessions, keys, and the audit log.

What each component owns

Component	Owns	Build or reuse
Edge	TLS termination, WAF rules, bot scoring, coarse rate limits	Reuse your CDN or cloud WAF
Login API and UI	Identifier-first flow, password and passkey sign-in, signup, recovery	Build: this is your brand experience
OAuth and OIDC server	`/authorize`, `/token`, `/userinfo`, JWKS, discovery, consent	Build on a certified library
Federation	SAML service provider and identity provider, social login, account linking	Build on a maintained SAML library
MFA and WebAuthn	TOTP, passkeys, recovery codes, step-up	Build on a WebAuthn server library
Risk engine	Scores each sign-in and sensitive action	Build the policy; buy signals if needed
Admin, SCIM, events	Tenant admin, user provisioning, webhooks	Build
User store	Users, identifiers, credentials, tenants	Relational database, per region
Session cache	Sessions, rate-limit counters, one-time codes	In-memory store with persistence
Key management	Token signing keys, pepper, encryption keys	Cloud KMS or HSM, never the app database
Audit log	Every security event, append-only	Event stream into immutable storage
Outbound messaging	Email and SMS delivery	Buy a provider; own templates and throttling

Five design rules I would not break

One identity layer. No product service validates passwords or issues sessions on its own. Everything else consumes tokens.
Stateless compute. Any identity service instance can serve any request. State lives in the stores.
Keys never live in the database. A database dump must not be enough to forge tokens or verify peppered hashes.
Region is a property of the user. Decide where each user's data lives at signup and route by it (Chapter 16).
Every security event is an audit event. If it is not in the log, it did not happen as far as your auditors and incident responders are concerned.

Warning

Common mistakes

Letting each product team add its own login endpoint.
Storing signing keys in environment variables or the user database.
Designing for one region and retrofitting residency later, which usually means a migration.

Key takeaways

Stateless identity services in front of a few guarded, regional data stores.
One identity layer: no product service validates passwords or issues sessions on its own.
Signing keys live in a KMS or HSM, never in the database or environment variables.
Decide a user's home region at signup; retrofitting residency means a migration.