Introduction
Modern distributed applications often run across multiple geographic regions for lower latency, compliance, and fault tolerance. In such systems, authentication and authorization become more complex because user traffic may not consistently hit the same backend region.
Most authentication architectures rely on one of these central dependencies:
A single cache layer (Redis, Memcached) for revocation lookups
A single authentication database
A single region key server
However, when systems are globally distributed, depending on a single centralized cache or authority increases latency and creates operational risks. A cache in one region cannot reliably serve requests in all regions without creating performance bottlenecks or failure points.
This article explains how to design a fully distributed token validation system where:
Token validation occurs locally in each region.
Tokens can still be revoked globally.
No central cache is required.
Propagation remains fast and reliable.
The result is a secure, fault-tolerant authentication system suitable for cloud-native, high-scale workloads.
The Core Problem
A token issued in one region (for example, India) must remain valid if the user travels and their request later goes to a different region (such as Europe or the United States). At the same time, if a token is revoked (logout, admin force revoke, suspected compromise), all regions must detect and block that token.
We must satisfy four conflicting goals:
| Requirement | Desired Behavior |
|---|
| Local Validation | Token must validate in the region receiving the request. |
| No Central Cache | No dependency on shared Redis or global DB. |
| Fast Revocation | Token revocation should propagate quickly worldwide. |
| Security | Compromised tokens must not remain usable. |
Balancing these goals is not trivial, especially if we allow authentication traffic to shift dynamically across regions.
Recommended Strategy
The most practical approach in production systems is a hybrid model combining:
Short-lived access tokens (JWT): fast, stateless validation.
Refresh tokens stored server-side: long-term authentication continuity.
Local revocation cache in each region: prevents compromised tokens.
Global event streaming for revocation propagation: push updates to each region.
Optional urgent push channel for critical revocations: immediate enforcement.
This design supports multi-region validation without querying a central system.
High-Level Architecture
┌─────────────────────────┐
│ Global Event Bus │
│ (Kafka / Event Hub / PS)│
└───────────────┬─────────┘
│
┌───────────────────────┼────────────────────────┐
│ │ │
┌───────▼───────┐ ┌───────▼───────┐ ┌───────▼───────┐
│ Region A API │ │ Region B API │ │ Region C API │
│ Local Cache │ │ Local Cache │ │ Local Cache │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
│ validate │ validate │ validate
│ token locally │ token locally │ token locally
│ │ │
└────────────────┬──────┴───────┬───────────────┘
│ │
┌─────▼────┐ ┌────▼──────┐
│ Clients │ │ Admin / │
│ (Mobile/ │ │ Auth API │
│ Browser) │ └───────────┘
└───────────┘
Token Structure
We use two token types.
Access Token (JWT)
Signed using RSA/ECDSA asymmetric keys so all regions can validate locally.
Refresh Token
Revocation Logic
When a user logs out or an admin revokes a token:
The session is revoked in the region of origin.
A revocation event is published to the global event bus.
Every region listens to this event and updates its local store.
Requests with revoked session IDs are rejected locally.
Token Validation Workflow
┌───────────────────┐
│ Client Request │
└─────────┬─────────┘
│
▼
┌───────────────────────┐
│ Validate Token Locally│
│ - Signature via JWK │
│ - Expiry Check │
│ - Session Check │
└─────────┬─────────────┘
│ valid?
│
┌─────▼──────┐
│ Allow API │
│ Execution │
└─────────────┘
If token is revoked locally → request is rejected immediately.
Handling Revocation Events
┌───────────────────────────┐
│ Revoke Session Request │
└───────────────┬──────────┘
│
▼
┌───────────────────────────┐
│ Update Local Store │
└───────────────┬──────────┘
│
▼
┌───────────────────────────┐
│ Publish Revoke Event │
└───────────────┬──────────┘
│
▼
┌───────┴───────────┐
│ Regional Consumers │
└───────────┬────────┘
│ update cache
▼
┌────────────────┐
│ New State Live │
└────────────────┘
.NET Backend Implementation Highlights
JWT Validation Middleware
var handler = new JwtSecurityTokenHandler();
var token = ExtractBearer(context.Request);
var principal = handler.ValidateToken(token, validationParameters, out var securityToken);
var sessionId = principal.FindFirst("sid")?.Value;
if (revocationStore.IsRevoked(sessionId))
{
context.Response.StatusCode = 401;
return;
}
Kafka Consumer Example
public async Task HandleRevocationEvent(SessionRevokedEvent message)
{
await revocationStore.SetAsync(
key: $"revoke:{message.SessionId}",
expiry: message.Expiry);
}
Angular Frontend Token Handling
Angular must:
Example interceptor snippet
intercept(req: HttpRequest<any>, next: HttpHandler) {
const token = this.auth.getToken();
if (token) {
req = req.clone({ setHeaders: { Authorization: `Bearer ${token}` } });
}
return next.handle(req);
}
Operational Considerations
| Topic | Best Practice |
|---|
| Key rotation | Use JWK URL and rotating RSA keys |
| Event replication | Measure delay; alert if above 5-10 seconds |
| Revocation TTL | Short token lifetime reduces risk |
| Forced logout | Use WebSockets for critical invalidation |
Testing Strategy
Simulate revoked tokens across regions.
Kill event bus connectivity and observe system correctness.
Measure worst-case window before revocation propagates.
Conclusion
A multi-region authentication system must prioritize performance, resilience, and security. By combining:
Short-lived signed access tokens
Refresh token rotation
Distributed revocation propagation
Local validation per region
You achieve an architecture that does not depend on a central cache while still enforcing global token invalidation.