Bird
Raised Fist0
Microservicessystem_design~12 mins

Centralized vs distributed auth in Microservices - Architecture Patterns Compared

Choose your learning style10 modes available
LearnWhyDeepArchPracticeChallengeDesignRecallScale

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
System Overview - Centralized vs distributed auth

This system compares two common ways to handle user authentication in microservices: centralized and distributed authentication. Centralized auth uses a single service to verify users, while distributed auth lets each microservice handle authentication itself. The goal is to understand how requests flow and how failures affect each approach.

Architecture Diagram
User
  |
  v
+-----------------+          +-------------------+          +----------------+
|  Load Balancer  |--------->|  API Gateway      |--------->| Auth Service   |
+-----------------+          +-------------------+          +----------------+
                                      |                             |
                                      |                             v
                                      |                      +------------+
                                      |                      | User DB    |
                                      |                      +------------+
                                      v
                             +-------------------+
                             | Microservice A    |
                             +-------------------+


Distributed Auth:
User
  |
  v
+-----------------+          +-------------------+          +-------------------+
|  Load Balancer  |--------->|  API Gateway      |--------->| Microservice A     |
+-----------------+          +-------------------+          +-------------------+
                                                               |          |
                                                               |          v
                                                               |    +------------+
                                                               |    | User DB    |
                                                               |    +------------+
Components
User
actor
Person or system making requests
Load Balancer
load_balancer
Distributes incoming requests evenly to API Gateway instances
API Gateway
api_gateway
Entry point for requests, routes to services and handles centralized auth calls
Auth Service
service
Centralized service that verifies user credentials and issues tokens
User DB
database
Stores user credentials and authentication data
Microservice A
service
Business logic service that either relies on centralized auth or performs its own auth
Request Flow - 13 Hops
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Auth Service
Auth Service → User DB
Auth Service → API Gateway
API Gateway → Microservice A
User → Load Balancer
Load Balancer → API Gateway
API Gateway → Microservice A
Microservice A → User DB
Microservice A → API Gateway
API Gateway → Load Balancer
Load Balancer → User
Failure Scenario
Component Fails:Auth Service
Impact:Centralized auth fails: users cannot authenticate or get tokens, so all requests requiring auth fail. Distributed auth services remain unaffected.
Mitigation:Use multiple Auth Service instances with load balancing and failover. For distributed auth, each microservice handles auth independently, reducing single points of failure.
Architecture Quiz - 3 Questions
Test your understanding
In centralized authentication, which component is responsible for verifying user credentials?
AAuth Service
BAPI Gateway
CMicroservice A
DLoad Balancer
Design Principle
This architecture demonstrates the trade-offs between centralized and distributed authentication. Centralized auth simplifies token management but creates a single point of failure. Distributed auth increases resilience by decentralizing authentication but adds complexity to each microservice.

Practice

(1/5)
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