Authentication Architecture Patterns

Authentication is the front door of every application. Get it wrong and nothing else matters — your database encryption, network segmentation, and monitoring are all bypassed. This guide covers practical authentication architecture for modern applications, not the theoretical RFC specs.

---

Auth Pattern Decision Tree

What type of application?
├── Server-rendered web app
│   └── Session-based auth (cookies)
│       Server stores session, cookie contains session ID
│
├── Single-page app (SPA)
│   └── OAuth 2.0 + PKCE
│       Authorization code flow with PKCE extension
│       Tokens stored in memory (not localStorage)
│
├── Mobile app
│   └── OAuth 2.0 + PKCE
│       Authorization code flow with PKCE
│       Tokens in secure enclave/keychain
│
├── API (machine-to-machine)
│   └── OAuth 2.0 Client Credentials
│       Service-to-service with client ID + secret
│
└── Microservices (internal)
    └── JWT propagation + mTLS
        Gateway validates, services trust JWT + mTLS

---

JWT Architecture

┌──────────┐       ┌──────────────┐       ┌──────────┐
│  Client  │──────▶│  Auth Server │──────▶│ Resource │
│          │       │  (issues JWT)│       │  Server  │
│          │       └──────────────┘       │(validates│
│          │              │                │  JWT)    │
│          │◀─── JWT ─────┘                │          │
│          │──── JWT in Authorization ────▶│          │
└──────────┘       header                 └──────────┘

JWT Best Practices

Practice	Implementation
Short expiry	Access token: 15 min, Refresh token: 7 days
Audience claim	aud: "api.example.com" — reject tokens for other APIs
Issuer validation	Verify iss claim matches your auth server
Algorithm pinning	Accept only RS256/ES256, reject none and HS256 from external
Key rotation	JWKS endpoint with key rotation every 90 days
Token binding	Bind token to client fingerprint where possible

---

Session vs JWT

Factor	Sessions (Cookies)	JWTs (Tokens)
Storage	Server-side (Redis/DB)	Client-side (stateless)
Revocation	Instant (delete session)	Hard (need blocklist or short TTL)
Scalability	Needs shared session store	Stateless, any server validates
CSRF risk	Yes (need CSRF tokens)	No (not auto-sent by browser)
XSS risk	Lower (httpOnly cookie)	Higher (if stored in localStorage)
Best for	Server-rendered apps	SPAs, mobile, microservices

---

Passwordless Authentication

Method	Security	UX	Implementation
Magic links (email)	Medium	Good	Email with one-time link
Passkeys (WebAuthn)	High	Excellent	Biometric/device-bound credential
SMS OTP	Low (SIM swap risk)	Fair	Avoid for sensitive apps
Authenticator app	High	Good	TOTP as second factor
Hardware key (FIDO2)	Highest	Fair	USB/NFC security key

---

Anti-Patterns

Anti-Pattern	Problem	Fix
JWT in localStorage	XSS can steal tokens	Memory storage + refresh via httpOnly cookie
Long-lived JWTs (24h+)	Stolen token valid for too long	15-min access token + refresh token rotation
No token revocation mechanism	Can’t invalidate compromised tokens	Token blocklist in Redis, or short TTL
Rolling your own auth	Inevitable security vulnerabilities	Use established providers (Auth0, Clerk, Supabase Auth)
Password-only auth	Phishing, credential stuffing	MFA mandatory, consider passkeys
Same secret for all environments	Dev compromise = prod compromise	Unique secrets per environment

---

Checklist

• Auth pattern selected based on application type
• OAuth 2.0 / OIDC implemented (not custom auth)
• JWT: short-lived (15 min), with refresh token rotation
• Token storage: secure (not localStorage for SPAs)
• MFA: mandatory for privileged accounts
• Session management: secure cookies, proper expiry
• CSRF protection for cookie-based auth
• Brute force protection: rate limiting on login
• Password policy: length over complexity, breach checking
• Key rotation: JWKS key rotation every 90 days

---

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For authentication architecture consulting, visit garnetgrid.com. :::