Daniel Cohen·
Auth design with rotating refresh tokens and passkeys-first MFA, even gave me the JWT claims shape
Designs a secure, scalable auth system supporting multiple flows including SSO, MFA, OAuth2/OIDC, RBAC/ABAC, and session management.
Authentication & Authorization System Design
Act as a Security Architect specializing in identity and access management (IAM). Design a comprehensive authentication and authorization system.
**Application Type**: {{application_type}} (SaaS platform, mobile app, enterprise B2B, consumer app)
**User Types**: {{user_types}} (end users, admins, API clients, service accounts, third-party integrations)
**Identity Sources**: {{identity_sources}} (local database, Google SSO, enterprise SAML/LDAP, social logins)
**Security Requirements**: {{security_requirements}} (MFA, passwordless, compliance (SOC2/ISO27001), breach history)
Design the complete auth system:
1. **Authentication Flows** - Username/password, OAuth2 Authorization Code + PKCE, SAML 2.0 SSO, magic links, WebAuthn/Passkeys, client credentials
2. **Identity Provider Architecture** - Self-hosted (Keycloak/Dex) vs managed (Auth0/AWS Cognito/Azure AD B2C) decision matrix
3. **Token Strategy** - JWT access tokens (RS256) + refresh tokens, opaque tokens, token binding, short-lived access tokens (5-15 min)
4. **Session Management** - Stateless JWT vs stateful sessions, Redis session store, concurrent session limits, device fingerprinting
5. **Multi-Factor Authentication** - TOTP (Google Authenticator), SMS OTP (with fallback warnings), WebAuthn/FIDO2, backup codes
6. **Password Policy** - NIST 800-63B compliant (minimum 8 chars, no complexity requirements, breach database checking), Argon2id hashing
7. **RBAC Design** - Role hierarchy, permission granularity (resource + action), role assignment API, default roles
8. **ABAC Extension** - Policy-based access with attributes (time, location, device, subscription tier), OPA/Rego policies
9. **API Security** - API key management (scoped, rotatable), mTLS for service-to-service, JWT validation middleware pattern
10. **Account Security Features** - Brute force protection (exponential backoff), account lockout, suspicious login detection, forced password reset
11. **Audit & Compliance** - Complete audit log schema (who, what, when, where, result), log retention, tamper-proof storage
12. **Token Revocation** - Revocation list strategy, logout flows, password change token invalidation, global sign-out
13. **OAuth2 Scope Design** - Granular scopes, consent screen design, third-party app approval workflow
Include sequence diagrams for login, token refresh, and logout flows, and sample JWT claims structure.
Ergebnisse
Auth system for a **B2B SaaS** (end users + admins + service accounts; Google SSO, enterprise SAML, local accounts; SOC2 + MFA). Short-lived JWTs, stateful refresh, passkeys first.
**Login (Authorization Code + PKCE)**
```
Client ─▶ /authorize (code_challenge) ─▶ IdP login + MFA
◀─ redirect ?code ──────────────
─▶ /token (code, code_verifier) ─▶ access JWT (10m) + refresh (rotating)
```
**Token strategy:** access tokens are RS256 JWTs, 10-min TTL, validated at the edge without a DB hit. Refresh tokens are opaque, stored server-side, and **rotate on every use** — a replayed refresh token revokes the whole chain (theft detection).
**Sample access-token claims:**
```json
{ "sub": "usr_812", "org": "org_44", "roles": ["admin"],
"scope": "orders:read orders:write", "exp": 1717250000, "amr": ["pwd", "otp"] }
```
**Authorization:** RBAC for coarse roles, ABAC (OPA/Rego) layered on for attribute rules like "only during business hours from a managed device". **MFA:** WebAuthn/passkeys primary, TOTP fallback, SMS only as a last resort with an explicit weak-factor warning. **Passwords:** NIST 800-63B — 8-char minimum, no forced complexity, checked against a breach corpus, hashed with Argon2id. **Logout & revocation:** refresh chain invalidated server-side; a short access-token TTL bounds the blast radius to 10 minutes. Every auth decision lands in an append-only audit log (who/what/when/where/result).
Modell: Claude Opus 4
89 Likes19 SavesScore: 69
4 Kommentare
Tobias Keller·
Works in TS strict mode with no complaints, which is rare.
Emily Chen·
The error handling is the part most examples skip. Nice to see it done right.
Marco Rossi·
Clean separation of concerns here, easy to drop into an existing service.
Ahmed Hassan·
Did not expect a system design prompt to be this thorough.