Centralized vs distributed auth in Microservices - Design Approaches Compared

Design: Authentication System for Microservices

Design covers authentication and authorization mechanisms for microservices. Does not cover user registration, password reset flows, or external identity providers integration.

Functional Requirements

FR1: Users must be able to log in and receive access tokens.

FR2: Microservices must verify user identity before granting access.

FR3: Support role-based access control (RBAC) across services.

FR4: Allow token revocation and session management.

FR5: Support scaling to 10,000 concurrent users.

FR6: Ensure low latency for authentication checks (p99 < 100ms).

FR7: Maintain 99.9% system availability.

Non-Functional Requirements

NFR1: Must work in a microservices environment with multiple independent services.

NFR2: Authentication data consistency must be maintained.

NFR3: Minimize network overhead for auth checks.

NFR4: Secure handling of credentials and tokens.

NFR5: Support both centralized and distributed authentication approaches.

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Authentication service (centralized or per service)

Token issuer and validator

API gateway or service mesh for auth enforcement

User database or directory

Cache for token validation

Logging and monitoring for auth events

Design Patterns

Centralized authentication with a dedicated auth service

Distributed authentication with local token validation

Token-based authentication (JWT)

Session management and token revocation

API gateway enforcing authentication

Service mesh with mutual TLS for service-to-service auth

Reference Architecture

                +---------------------+
                |   User / Client App  |
                +----------+----------+
                           |
                           | Login Request (username/password)
                           v
                +---------------------+          +---------------------+
                | Centralized Auth     |          | User Database       |
                | Service (OAuth2, JWT)|<-------->| (e.g., PostgreSQL)  |
                +----------+----------+          +---------------------+
                           |
           Issue JWT Token  |
                           v
                +---------------------+
                | API Gateway /        |
                | Service Mesh         |
                +----------+----------+
                           |
          Forward requests with JWT token
                           v
                +---------------------+
                | Microservices        |
                | (Validate JWT locally|
                | or via Auth Service) |
                +---------------------+

Components

Centralized Auth Service

OAuth2 server with JWT tokens

Handles user login, issues signed JWT tokens, manages token revocation and session state.

User Database

Relational DB (PostgreSQL)

Stores user credentials, roles, and permissions.

API Gateway / Service Mesh

Kong, Istio, or Envoy

Enforces authentication by validating tokens before forwarding requests to microservices.

Microservices

Various (Node.js, Java, etc.)

Perform business logic; validate JWT tokens locally or call Auth Service for validation.

Cache

Redis

Cache token validation results to reduce latency and load on Auth Service.

Request Flow

1. User sends login request with credentials to Centralized Auth Service.

2. Auth Service validates credentials against User Database.

3. If valid, Auth Service issues a signed JWT token with user roles and expiry.

4. User includes JWT token in Authorization header for API requests.

5. API Gateway or Service Mesh validates JWT token signature and expiry.

6. If valid, request is forwarded to target microservice.

7. Microservice optionally validates token locally or queries Auth Service for token status.

8. Microservice enforces role-based access control based on token claims.

9. For token revocation, Auth Service maintains a blacklist or uses short-lived tokens with refresh.

Database Schema

Entities: - User: id (PK), username, password_hash, email - Role: id (PK), name - UserRole: user_id (FK), role_id (FK) - TokenBlacklist: token_id, expiry Relationships: - User to Role is many-to-many via UserRole - TokenBlacklist stores revoked tokens to prevent reuse

Scaling Discussion

Bottlenecks

Centralized Auth Service can become a single point of failure and bottleneck under high load.

Database can be overwhelmed by frequent credential checks and role queries.

Token validation latency can add overhead to every API request.

Token revocation requires synchronization and can be complex with distributed caches.

Solutions

Scale Auth Service horizontally behind a load balancer with stateless JWT tokens to reduce state dependency.

Use caching (Redis) for user roles and token validation results to reduce DB load.

Adopt short-lived JWT tokens with refresh tokens to minimize revocation complexity.

Implement distributed token validation by embedding claims in JWT and validating signature locally in microservices.

Use API Gateway or service mesh to offload token validation from microservices.

Use database read replicas and connection pooling to handle increased DB load.

Interview Tips

Time: Spend 10 minutes understanding requirements and clarifying scope, 20 minutes designing architecture and data flow, 10 minutes discussing scaling and trade-offs, 5 minutes summarizing.

Explain difference between centralized and distributed authentication.

Discuss pros and cons of JWT tokens and token revocation strategies.

Highlight importance of caching and stateless tokens for scalability.

Mention security considerations like token signing and expiry.

Describe how API Gateway or service mesh can enforce auth.

Discuss how microservices validate tokens locally to reduce latency.

Practice

1. What is the main characteristic of centralized authentication in microservices?

easy

A. No authentication is required between services

B. Each microservice verifies user identity independently

C. Authentication is done by the client application only

D. A single service handles all user login and identity verification

Solution

1. Step 1: Understand centralized authentication

   Centralized authentication means one dedicated service manages all login and identity checks for the system.

2. Step 2: Compare with other options

   Distributed auth where each service verifies independently, client-only auth, or no auth are not centralized.

3. Final Answer:

   A single service handles all user login and identity verification -> Option D

4. Quick Check:

   Centralized auth = single service [OK]

Hint: Centralized means one place handles all auth [OK]

Common Mistakes:

• Confusing centralized with distributed auth
• Thinking each service handles login in centralized auth
• Assuming client-only authentication is centralized

2. Which of the following is a typical token used in distributed authentication?

easy

A. OAuth 2.0 access token

B. SQL query string

C. HTML cookie without signature

D. Plain text password

Solution

1. Step 1: Identify token types in distributed auth

   Distributed authentication commonly uses tokens like OAuth 2.0 access tokens to verify identity without contacting a central service each time.

2. Step 2: Eliminate incorrect options

   SQL queries, unsigned cookies, and plain text passwords are not secure tokens used for distributed auth.

3. Final Answer:

   OAuth 2.0 access token -> Option A

4. Quick Check:

   Distributed auth token = OAuth 2.0 token [OK]

Hint: OAuth tokens are standard for distributed auth [OK]

Common Mistakes:

• Confusing SQL queries with tokens
• Using unsigned cookies as secure tokens
• Thinking plain text passwords are tokens

3. Consider a microservice system where each service validates JWT tokens locally without contacting a central auth server. What is the main advantage of this approach?

medium

A. Reduced latency and less dependency on a central service

B. Simpler token revocation management

C. Centralized control over user sessions

D. No need for token expiration

Solution

1. Step 1: Understand local JWT validation

   When services validate JWT tokens locally, they avoid network calls to a central auth server, reducing latency and dependency.

2. Step 2: Analyze other options

   Token revocation is harder locally, centralized control over user sessions is lost, and tokens still need expiration.

3. Final Answer:

   Reduced latency and less dependency on a central service -> Option A

4. Quick Check:

   Distributed auth local validation = less latency [OK]

Hint: Local token checks speed up requests [OK]

Common Mistakes:

• Assuming token revocation is easier locally
• Thinking local validation means centralized control
• Ignoring token expiration needs

4. A microservice system uses centralized authentication but experiences frequent downtime of the auth service. What is the best way to fix this issue?

medium

A. Use plain text passwords for faster login

B. Remove authentication completely

C. Implement caching of authentication tokens in services

D. Make each service validate tokens independently without central auth

Solution

1. Step 1: Identify problem with centralized auth downtime

   Downtime of the central auth service causes failures in login or token validation.

2. Step 2: Choose a solution to reduce dependency

   Caching tokens locally in services reduces calls to the central auth, improving availability without removing auth or security.

3. Final Answer:

   Implement caching of authentication tokens in services -> Option C

4. Quick Check:

   Fix downtime by caching tokens [OK]

Hint: Cache tokens to reduce auth service calls [OK]

Common Mistakes:

• Removing authentication entirely
• Switching to insecure plain text passwords
• Switching to distributed auth without planning

5. You are designing a large microservices system that requires high security and low latency. Which authentication approach best balances these needs?

hard

A. Centralized authentication with synchronous calls for every request

B. Distributed authentication using signed tokens validated locally with periodic revocation checks

C. No authentication to maximize speed

D. Centralized authentication with no token expiration

Solution

1. Step 1: Analyze security and latency needs

   High security requires token validation and revocation; low latency requires avoiding frequent central calls.

2. Step 2: Evaluate options

   Distributed authentication using signed tokens validated locally with periodic revocation checks uses signed tokens validated locally to reduce latency and periodic revocation checks to maintain security. Centralized authentication with synchronous calls for every request causes latency, no authentication is insecure, and centralized authentication with no token expiration risks stale sessions.

3. Final Answer:

   Distributed authentication using signed tokens validated locally with periodic revocation checks -> Option B

4. Quick Check:

   Balance security and speed with distributed tokens [OK]

Hint: Use local token checks plus revocation for security and speed [OK]

Common Mistakes:

• Choosing no authentication for speed
• Ignoring token expiration and revocation
• Relying on central auth for every request causing latency