A Modern Security Architecture for Microservices | Phạm Duy Khánh [thisisduykhanh]

Design, Implementation, and Evaluation Using Spring Security, JWT, Policy-Based Authorization, and Redis

Abstract

Microservice architectures introduce significant security challenges due to their distributed nature, dynamic scaling, and multi-tenant requirements. Traditional role-based access control mechanisms often fail to provide sufficient flexibility and contextual awareness. This paper presents a modern security architecture built on the Spring ecosystem, combining JWT-based authentication, policy-based authorization (PBAC), API Gateway rate limiting, and Redis-backed caching. The proposed architecture emphasizes separation of concerns, performance, and extensibility. A real-world implementation is analyzed to evaluate its security properties and operational characteristics.

1. Overall Architecture Diagram

1.1 High-Level System Architecture

+-------------------+
|      Client       |
| (Web / Mobile /   |
|  Service-to-Serv) |
+---------+---------+
|
v
+----------------------------+
|        API Gateway         |
|----------------------------|
| - Rate Limiting            |
| - IP / User-based Key      |
+-------------+--------------+
|
v
+----------------------------+
|   Resource Server (API)    |
|----------------------------|
| Spring Security            |
| - JWT Authentication       |
| - Custom Principal Mapping |
+-------------+--------------+
|
v
+----------------------------+
| Authorization Layer        |
|----------------------------|
| Policy Provider            |
| Policy Evaluator           |
| Context-aware Decisions    |
+-------------+--------------+
|
v
+----------------------------+
| Redis Cache                |
|----------------------------|
| - User Policy Cache        |
| - TTL-based Eviction       |
+-------------+--------------+
|
v
+----------------------------+
| Business Services          |
+----------------------------+

1.2 Request Processing Sequence

Client
|
| 1. HTTP Request + JWT
v
API Gateway
|-- Rate Limit Check
|
v
Spring Security Filter Chain
|-- JWT Verification
|-- Identity Projection
|
v
Authorization Service
|-- Load Policies (Redis / DB)
|-- Evaluate ALLOW / DENY
|
v
Controller / Service Layer

2. Security Design and Conceptual Model

2.1 Design Principles

The architecture is guided by the following principles:

Zero Trust

Every request must be authenticated and authorized

Separation of Concerns

Authentication ≠ Authorization

Explicit Deny

DENY rules override ALLOW rules

Context Awareness

Authorization decisions may depend on request metadata

Performance First

Authorization must be fast enough for per-request evaluation

2.2 Authentication Model

The system adopts a JWT-based OAuth2 Resource Server model:

JWTs are signed using RSA asymmetric keys
The Resource Server validates tokens locally
No runtime dependency on the Authorization Server

Security Advantages:

Stateless authentication
Horizontal scalability
Reduced attack surface

2.3 Identity Projection

Instead of using raw JWT claims across the application, the system introduces a domain-specific identity abstraction:

UserIdentity {
userId
principalType
tenantId
}

This abstraction:

Decouples application logic from token structure
Supports multi-tenancy
Enables future authentication mechanisms (API keys, mTLS)

2.4 Policy-Based Authorization Model (PBAC)

Authorization is implemented using a policy-based model, defined as:

Policy = {
effect: ALLOW | DENY
action: String
resource: String
condition: Optional
}

Key characteristics:

Wildcard-based matching (*)
Implicit deny (default)
Deterministic evaluation order

This model is conceptually aligned with:

AWS IAM
XACML (simplified)
Open Policy Agent (OPA)

2.5 Context-Aware Authorization

Authorization decisions are not purely identity-based. Each decision may include runtime context:

Context = {
ip_address,
user_agent,
request_metadata
}

This enables:

Risk-based access control
Device-aware authorization
Geo or behavior-based policies

3. Implementation Details

3.1 API Gateway Rate Limiting

Rate limiting is enforced at the gateway using a KeyResolver:

IP-based (default)
User-based (optional)

This protects downstream services from:

Abuse
Brute-force attacks
Accidental overload

3.2 Spring Security Configuration

The system uses:

SecurityFilterChain
OAuth2 Resource Server
Custom JwtAuthenticationConverter

JWTs are converted into a domain-specific authentication token:

IdentityAuthenticationToken → UserIdentity

This ensures consistent identity handling across the system.

3.3 Authorization Service Flow

AuthorizationFacade
↓
AuthorizationService
↓
PolicyProvider (Cached)
↓
PolicyEvaluator

Policies are evaluated per request
DENY rules are checked before ALLOW rules
Matching is performed using cached compiled regex patterns

3.4 Redis-Based Policy Caching

Policies are cached using Redis:

Cache key: (tenantId + userId)
TTL configurable per cache
Null values are not cached

Benefits:

O(1) access time
Reduced database load
Predictable latency

3.5 Secure Serialization Strategy

To prevent deserialization vulnerabilities:

Polymorphic typing is restricted
Only trusted packages are allowed
Default typing is tightly controlled

This mitigates common Jackson-based RCE attacks.

3.6 Error Handling and API Consistency

A global exception handler ensures:

No sensitive error details are leaked
HTTP status codes align with security semantics
Error responses are standardized

This aligns with OWASP API Security recommendations.

4. Evaluation

4.1 Security Analysis

Aspect	Evaluation
Authentication	Stateless, scalable
Authorization	Deterministic, auditable
Policy Override	Explicit DENY
Attack Surface	Reduced
Deserialization Safety	Strong

4.2 Performance Considerations

Authorization latency: sub-millisecond (cached)
Regex compilation cached per policy
Redis reduces DB dependency significantly

5. Limitations and Future Work

Current Limitations

Policy conditions not yet evaluated
No authorization decision audit log
Regex matching may degrade with large policy sets

Future Enhancements

Condition DSL (CEL / SpEL)
Decision result caching
Policy versioning
Distributed cache invalidation
mTLS for internal services

6. Conclusion

This paper demonstrates that a robust and scalable security architecture for microservices can be achieved using well-defined abstractions, policy-based authorization, and strategic caching. The presented design balances security, performance, and extensibility, making it suitable for production-grade, multi-tenant systems.