Multi-Region Token Validation Without a Central Cache

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)

Valid for 2 to 5 minutes.
Contains:
- jti (token ID)
- sid (session ID)
- iat, exp
- Claims like sub, roles.

Signed using RSA/ECDSA asymmetric keys so all regions can validate locally.

Refresh Token

Opaque token
Stored server-side in the authentication system.
Rotated during refresh operations.

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:

Store access + refresh token securely (prefer session storage + memory).
Refresh tokens silently.
Handle forced logout events.

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.