Auth Architecture Redesign
Comparison of the session-cookie system (current) against the proposed token-based architecture — covering security posture, scalability, and operational complexity.
Architecture Overview
What changes between the two approaches.
✕ Current — Session Cookies
Server-side session store — Redis cluster holds all active sessions. Single point of failure.
Sticky sessions required — Load balancer must route requests to the originating node or share the session store.
Cookie-only — Mobile apps and third-party integrations require workarounds.
No fine-grained expiry — Session lifetime is global; can't scope by device or permission level.
✓ Proposed — JWT + Refresh Tokens
Stateless access tokens — Services validate JWTs locally without a shared store. No Redis dependency per request.
Short-lived access (15 min) + long-lived refresh (30 days) — Rotating refresh tokens stored server-side for revocation.
Bearer token — Works natively for mobile apps, SPAs, and API integrations with no workaround.
Scoped claims — Token payload carries roles and permissions; reduces DB lookups on each request.
Key Metrics Comparison
Quantitative differences where measurable.
Auth latency (p99)
~85 ms
→
~12 ms
Redis reads per request
1 (mandatory)
→
0 (access token)
Mobile client support
Workaround needed
→
Native
Token revocation
Immediate
→
Up to 15 min lag (access token TTL)
Migration effort
—
→
~3 weeks (all services)
Recommendation
Proceed with JWT + refresh tokens
The latency and scalability gains outweigh the migration cost. The only meaningful regression is the 15-minute revocation window for access tokens — mitigate this by keeping access token TTL at 15 minutes and ensuring refresh token rotation on every use. Begin with non-critical services and validate the revocation flow before migrating the auth service itself.