Centralized vs distributed auth in Microservices - Architecture Trade-offs

Problem Statement

When each microservice manages its own user authentication, inconsistencies arise, leading to security gaps and poor user experience. Without a unified approach, users may need to log in multiple times, and managing permissions becomes error-prone and complex.

Solution

Centralized authentication delegates all user login and token issuance to a single trusted service, which microservices then verify. Distributed authentication embeds user identity and permissions within tokens that microservices validate independently, reducing dependency on a central service.

Architecture

Client App

Client App

↓

Auth Service

Auth Service

↓

Microservice

Microservice

↓

Client App

Client App

↓

Auth Service

Auth Service

↓

Microservice1

Microservice1

↓

Microservice2

Microservice2

The diagram shows two approaches: centralized auth where microservices rely on a single auth service for token validation, and distributed auth where microservices independently validate signed tokens without contacting the auth service.

Trade-offs

✓ Pros

→

Centralized auth simplifies user session management and revocation by having a single source of truth.

→

Distributed auth reduces latency and dependency on the auth service during token validation.

→

Distributed auth scales better as microservices validate tokens locally without network calls.

✗ Cons

→

Centralized auth creates a single point of failure and potential bottleneck if the auth service is down or slow.

→

Distributed auth complicates token revocation and requires secure token signing and verification.

→

Centralized auth can increase latency due to network calls for each token validation.

Use centralized auth when you need strict control over sessions, easy revocation, and simpler auditing, especially if your system has moderate scale and low tolerance for stale permissions.

Avoid centralized auth when your system has very high request rates or requires low latency, as the auth service can become a bottleneck or single point of failure.

Real World Examples

Netflix

Uses centralized authentication with a dedicated auth service to manage user sessions and permissions across many microservices.

Uber

Implements distributed authentication using signed tokens (JWT) so microservices can independently verify user identity without contacting a central service.

Amazon

Employs a hybrid approach where tokens are issued centrally but microservices validate them locally to balance control and scalability.

Code Example

The before code shows centralized auth where each token validation requires a network call to the auth service, causing latency and dependency. The after code uses distributed auth by locally verifying the JWT token signature and expiry, eliminating network calls and improving scalability.

Microservices

Before (Centralized Auth - naive token check with network call):

import requests

def is_token_valid(token):
    response = requests.post('https://auth.service/validate', json={'token': token})
    return response.status_code == 200

After (Distributed Auth - local JWT verification):

import jwt

SECRET_KEY = 'secret'

def is_token_valid(token):
    try:
        payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        return True
    except jwt.ExpiredSignatureError:
        return False
    except jwt.InvalidTokenError:
        return False

Alternatives

API Gateway Authentication

Authentication is handled at the gateway layer before requests reach microservices, offloading auth logic from services.

Use when: Use when you want to centralize auth checks at the edge and keep microservices simpler.

Session-based Authentication

Uses server-stored sessions instead of tokens, requiring stateful session management.

Use when: Choose when you need tight control over sessions and can afford stateful infrastructure.

Summary

Centralized authentication relies on a single service to validate user tokens, simplifying session control but risking bottlenecks.

Distributed authentication lets microservices verify signed tokens locally, improving scalability and reducing latency.

Choosing between them depends on system scale, latency needs, and how tightly you must control user sessions.

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