Authentication & Authorization Flow π
This document explains the complete authentication and authorization flow used in ShopVerse, from user login to secured service access.
The design focuses on centralized security, stateless authentication, and scalable authorization, following real-world backend practices.
π― Design Goalsβ
- Authenticate users once
- Avoid duplicating security logic across services
- Keep microservices lightweight
- Ensure secure inter-service trust
- Support role-based access control (RBAC)
π§ High-Level Strategyβ
ShopVerse uses:
- JWT-based authentication
- API Gatewayβlevel validation
- Header-based identity propagation
- RBAC enforcement at services
This ensures security without tight coupling.
π Authentication Flow (Step-by-Step)β
1οΈβ£ User Loginβ
- Client sends credentials to Auth Service
- Auth Service validates credentials
- JWT token is issued
2οΈβ£ Token Usageβ
- Client sends JWT in
Authorizationheader - All requests go through API Gateway
3οΈβ£ Gateway Validationβ
- Gateway validates JWT signature & expiration
- Extracts user identity and role
- Removes
Authorizationheader - Injects trusted headers:
X-User-EmailX-User-Role
4οΈβ£ Downstream Authorizationβ
- Services trust gateway-injected headers
- Role-based access control is enforced locally
- No JWT parsing inside services
ποΈ Authentication Flow Diagram (Mermaid)β
π JWT Token Structureβ
The JWT issued by Auth Service contains:
{
"sub": "user@example.com",
"role": "CUSTOMER",
"name": "User Name",
"iat": 1710000000,
"exp": 1710003600
}
Key Claims:β
subβ User identity (email)roleβ Authorization roleexpβ Token expiration
π§© API Gateway Responsibilitiesβ
The API Gateway is the security backbone.
Responsibilities:β
- JWT validation
- Token expiration checks
- Role extraction
- Header enrichment
- Blocking unauthorized requests
Why Validate JWT at Gateway?β
- Avoid duplicate JWT parsing
- Faster downstream services
- Centralized security changes
- Reduced attack surface
π Header-Based Trust Modelβ
After validation, the gateway forwards requests with trusted headers:
X-User-Email: user@example.com
X-User-Role: CUSTOMER
Downstream services:
- Do not accept raw JWT tokens
- Trust only gateway-provided headers
- Authenticate requests internally using a custom filter
π‘οΈ Service-Level Authorizationβ
Each service enforces RBAC using:
OncePerRequestFilter- Spring Security
SecurityContext - Role-based method or endpoint protection
Example:β
ADMINβ Create / Update / DeleteCUSTOMERβ Read / Order / Pay
π§ Why This Approach Worksβ
| Concern | Solution |
|---|---|
| Security duplication | Centralized at gateway |
| Token tampering | JWT signature validation |
| Performance | Single JWT validation |
| Scalability | Stateless auth |
| Service simplicity | Header-based auth |
β οΈ Failure Scenariosβ
β Invalid / Expired Tokenβ
- Gateway blocks request
- Returns
401 Unauthorized
β Missing Headersβ
- Service rejects request
- Returns
403 Forbidden
β Gateway Downβ
- Entire system protected
- No insecure direct access
π Scalability Benefitsβ
- Gateway can scale horizontally
- Services remain stateless
- No session storage required
- Easy to integrate new services
π§© Alternative Approaches (Why Not Used)β
| Approach | Reason Not Used |
|---|---|
| Session-based auth | Not scalable |
| JWT validation in every service | Duplication |
| Shared auth DB | Tight coupling |
π Summaryβ
ShopVerse uses a gateway-centric JWT authentication model that ensures:
- Centralized security
- Clean service boundaries
- High performance
- Easy scalability
- Interview-ready explanation
This approach mirrors real-world microservice security designs.