Bird
Raised Fist0
Microservicessystem_design~25 mins

Authentication at gateway level in Microservices - System Design Exercise

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Design: Authentication at Gateway Level in Microservices
Design focuses on authentication at the API gateway level in a microservices architecture. Authorization inside microservices and user management systems are out of scope.
Functional Requirements
FR1: Authenticate all incoming client requests before routing to microservices
FR2: Support token-based authentication (e.g., JWT)
FR3: Validate tokens efficiently to minimize latency
FR4: Allow unauthenticated access to public endpoints
FR5: Provide detailed error responses for authentication failures
FR6: Support role-based access control (RBAC) for downstream services
FR7: Log authentication attempts for auditing
FR8: Handle 10,000 concurrent requests with p99 latency under 150ms
FR9: Ensure 99.9% uptime for the authentication gateway
Non-Functional Requirements
NFR1: Authentication must happen only once at the gateway to reduce load on microservices
NFR2: Gateway should not become a single point of failure
NFR3: Token validation should be stateless to support horizontal scaling
NFR4: Latency added by authentication should be minimal
NFR5: System must be secure against common attacks (replay, token forgery)
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
❓ Question 6
Key Components
API Gateway
Authentication Service or Identity Provider
Token Validation Module
Cache for token validation results
Logging and Monitoring System
Load Balancer
Microservices behind the gateway
Design Patterns
API Gateway Pattern
Token-based Authentication (JWT)
Stateless Authentication
Circuit Breaker for downstream services
Caching for token validation
Fail-fast authentication
Reference Architecture
Client
  |
  v
API Gateway (Auth Layer)
  |-- Token Validation (JWT)
  |-- Public Endpoint Bypass
  |-- Logging
  |
  v
Load Balancer
  |
  v
Microservices
  |
  v
Database / Identity Provider
Components
API Gateway
Nginx with Lua scripts or Kong Gateway
Entry point for all client requests; performs authentication and routes requests
Token Validation Module
Stateless JWT validation library
Validate token signature, expiry, and claims without external calls
Cache
Redis or in-memory cache
Cache token validation results to reduce repeated computation
Logging System
ELK Stack (Elasticsearch, Logstash, Kibana)
Store and analyze authentication logs for auditing and monitoring
Load Balancer
HAProxy or cloud provider load balancer
Distribute requests to multiple gateway instances for high availability
Microservices
Various (e.g., Spring Boot, Node.js)
Business logic services that trust gateway authentication
Identity Provider
OAuth2 / OpenID Connect server (e.g., Keycloak)
Issue tokens and manage user authentication
Request Flow
1. Client sends request with token to API Gateway
2. API Gateway checks if endpoint is public; if yes, forwards request without authentication
3. If authentication required, Gateway extracts token from request header
4. Gateway checks cache for token validation result to speed up processing
5. Gateway validates token signature and expiry locally using Token Validation Module
6. If token is invalid or expired, Gateway returns 401 Unauthorized response
7. If token is valid, Gateway logs authentication success
8. Gateway forwards authenticated request to appropriate microservice
9. Microservice processes request assuming authentication is done
10. Response flows back through Gateway to Client
Database Schema
Entities: - User (id, username, password_hash, roles) - Token (token_id, user_id, issued_at, expires_at, revoked) - Role (role_id, role_name) - Permission (permission_id, permission_name) Relationships: - User has many Roles (many-to-many) - Role has many Permissions (many-to-many) - Token belongs to User Note: Token storage is optional if using stateless JWT; revocation can be handled via blacklist or short expiry.
Scaling Discussion
Bottlenecks
API Gateway becoming a single point of failure under high load
Token validation CPU overhead if done synchronously for every request
Cache consistency for token revocation or expiry
Logging system overload with high authentication traffic
Solutions
Deploy multiple API Gateway instances behind a load balancer for redundancy and load distribution
Use stateless JWT validation to avoid external calls and reduce latency
Implement short token expiry and use cache with TTL to balance performance and revocation accuracy
Use asynchronous logging and log aggregation tools to handle high volume efficiently
Interview Tips
Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.
Explain why authentication at the gateway reduces load on microservices
Discuss stateless JWT validation benefits and challenges
Highlight importance of caching token validation results
Mention handling of public endpoints and error responses
Address scaling strategies and fault tolerance
Show awareness of security concerns like token revocation and replay attacks

Practice

(1/5)
1. What is the main benefit of performing authentication at the gateway level in a microservices architecture?
easy
A. It slows down the request processing by adding extra steps.
B. It allows each microservice to handle its own authentication independently.
C. It eliminates the need for authorization in microservices.
D. It centralizes authentication, reducing repeated checks in each microservice.

Solution

  1. Step 1: Understand the role of gateway authentication

    Authentication at the gateway means checking user identity once before requests reach microservices.
  2. Step 2: Identify benefits of centralizing authentication

    This reduces repeated authentication logic inside each microservice, improving maintainability and security.
  3. Final Answer:

    It centralizes authentication, reducing repeated checks in each microservice. -> Option D
  4. Quick Check:

    Centralized authentication = It centralizes authentication, reducing repeated checks in each microservice. [OK]
Hint: Gateway authentication centralizes checks, avoiding repetition [OK]
Common Mistakes:
  • Thinking each microservice should authenticate independently
  • Confusing authentication with authorization
  • Assuming gateway authentication slows down system
2. Which of the following is the correct way to implement authentication at the gateway level?
easy
A. The gateway validates user tokens and forwards requests with user info.
B. The gateway forwards requests without checking authentication.
C. Each microservice validates user tokens independently.
D. Microservices share a database to authenticate users directly.

Solution

  1. Step 1: Identify gateway's role in token validation

    The gateway should validate user tokens to confirm identity before forwarding requests.
  2. Step 2: Understand forwarding with user info

    After validation, the gateway forwards requests including user identity details for downstream services.
  3. Final Answer:

    The gateway validates user tokens and forwards requests with user info. -> Option A
  4. Quick Check:

    Gateway validates tokens = The gateway validates user tokens and forwards requests with user info. [OK]
Hint: Gateway validates tokens, then forwards requests with user info [OK]
Common Mistakes:
  • Letting microservices validate tokens independently
  • Not validating tokens at the gateway
  • Using shared database for authentication in microservices
3. Consider this simplified request flow code snippet at the gateway:
function handleRequest(request) {
  const token = request.headers['Authorization'];
  if (!validateToken(token)) {
    return { status: 401, message: 'Unauthorized' };
  }
  return forwardRequest(request);
}
What will happen if validateToken always returns false?
medium
A. All requests will be forwarded to microservices.
B. Requests without tokens will be forwarded, others rejected.
C. All requests will be rejected with 401 Unauthorized.
D. Gateway will crash due to invalid token handling.

Solution

  1. Step 1: Analyze the token validation condition

    If validateToken(token) returns false, the code returns 401 Unauthorized immediately.
  2. Step 2: Determine effect on all requests

    Since it always returns false, no requests pass validation, so all are rejected with 401.
  3. Final Answer:

    All requests will be rejected with 401 Unauthorized. -> Option C
  4. Quick Check:

    Always false validation = 401 rejection [OK]
Hint: False validation means all requests rejected [OK]
Common Mistakes:
  • Assuming requests are forwarded despite failed validation
  • Thinking gateway crashes on invalid token
  • Ignoring the immediate return on failed validation
4. A gateway is designed to authenticate requests but sometimes forwards unauthorized requests to microservices. What is the most likely cause?
medium
A. The gateway does not check the token before forwarding.
B. The gateway caches old valid tokens and skips validation.
C. The gateway uses synchronous token validation.
D. Microservices override the gateway authentication.

Solution

  1. Step 1: Identify why unauthorized requests pass

    If the gateway caches tokens and skips validation, expired or revoked tokens may be accepted.
  2. Step 2: Understand caching impact on authentication

    Cached tokens can cause stale validation results, allowing unauthorized requests through.
  3. Final Answer:

    The gateway caches old valid tokens and skips validation. -> Option B
  4. Quick Check:

    Token caching causes stale auth = The gateway caches old valid tokens and skips validation. [OK]
Hint: Stale token cache causes unauthorized forwarding [OK]
Common Mistakes:
  • Assuming microservices override gateway auth
  • Ignoring token caching effects
  • Confusing synchronous validation with forwarding issues
5. You are designing a microservices system with authentication at the gateway level. To ensure high availability and avoid a single point of failure, which design approach is best?
hard
A. Deploy multiple gateway instances behind a load balancer with shared session storage.
B. Use a single gateway instance with a backup database for tokens.
C. Let each microservice authenticate independently to avoid gateway failure.
D. Disable authentication at the gateway and rely on microservices.

Solution

  1. Step 1: Identify high availability needs for gateway

    Multiple gateway instances prevent downtime if one fails, improving reliability.
  2. Step 2: Understand role of load balancer and shared session storage

    Load balancer distributes requests; shared session storage keeps authentication state consistent across gateways.
  3. Final Answer:

    Deploy multiple gateway instances behind a load balancer with shared session storage. -> Option A
  4. Quick Check:

    Multiple gateways + load balancer = high availability [OK]
Hint: Use multiple gateways with load balancer for reliability [OK]
Common Mistakes:
  • Relying on single gateway instance only
  • Ignoring session consistency across gateways
  • Disabling gateway authentication entirely