<aside>
🔐
Stateless Identity in Microservices
AuthN vs AuthZ, JWT, and the evolution to fine‑grained authorization (PDP/PEP)
</aside>
<aside>
⚡
Read time
~8–10 minutes
</aside>
<aside>
🧭
Audience
Architects + senior engineers shipping distributed systems
</aside>
<aside>
🎯
Goal
Design identity & authorization that scales without central session state
</aside>
0) Executive summary (the 30‑second version)
- Authentication (AuthN) answers: Who is calling? → handled by an Identity Provider (IdP).
- Authorization (AuthZ) answers: Are they allowed to do this action on this resource in this context? → enforced by PEP and decided by a PDP.
- JWT access tokens enable stateless request processing because identity + coarse permissions travel with each request.
- As systems grow, RBAC alone breaks (role explosion). Modern systems evolve toward PBAC/ABAC/ReBAC with centralized policy.
1) The paradigm shift: sessions → stateless tokens
<aside>
🏗️
A microservice architecture wants horizontal scaling and failure isolation. That’s incompatible with a single, central session store on the critical path of every request.
</aside>
Why stateful sessions become a bottleneck
- Shared session DB/cache becomes a hot dependency (latency + availability coupling).
- Sticky sessions complicate multi-region, autoscaling, and failover.
- Each request needs a server-side lookup → extra network hop.
What “stateless” actually means (and doesn’t)
| Term |
Meaning |
Common misconception |
| Stateless API |
Each request is independently verifiable and carries required context (token). |
“No state exists anywhere.” (State still exists in DBs, caches, policy stores.) |
| Stateless auth |
No per-session server storage needed to authenticate a request. |
“Logout/revocation is free.” (It’s not.) |
2) AuthN vs AuthZ (crisp separation)