Service-to-service authentication in Microservices - System Design Exercise

Design: Service-to-Service Authentication System

Design focuses on authentication between microservices only. Authorization, user authentication, and API gateway design are out of scope.

Functional Requirements

FR1: Allow microservices to securely authenticate with each other without user involvement

FR2: Support token-based authentication with short-lived tokens

FR3: Enable services to verify the identity of calling services

FR4: Provide a centralized authentication service for issuing and validating tokens

FR5: Ensure tokens cannot be easily forged or reused after expiration

FR6: Support revocation of tokens in case of compromise

FR7: Allow easy integration with existing microservices architecture

Non-Functional Requirements

NFR1: Must handle up to 10,000 service-to-service authentication requests per second

NFR2: Token validation latency should be under 50ms (p99)

NFR3: System availability must be at least 99.9% uptime

NFR4: Tokens should expire within 5 minutes to reduce risk

NFR5: Authentication service must be horizontally scalable

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

Key Components

Authentication Service (Token Issuer)

Token Validation Library or Middleware in each service

Secure Storage for keys or secrets

Service Registry or Discovery

Revocation List or Cache

Logging and Monitoring

Design Patterns

OAuth 2.0 Client Credentials Flow

JWT (JSON Web Tokens) for stateless tokens

Mutual TLS (mTLS) for service identity

Token Introspection Endpoint

Caching token validation results

Reference Architecture

                    +-----------------------+
                    |   Authentication       |
                    |       Service          |
                    |  (Token Issuer &       |
                    |   Validator)           |
                    +-----------+-----------+
                                |
                                | Issue tokens (JWT)
                                |
+----------------+      +-------v--------+      +----------------+
|  Microservice 1 | ---> | Token Validation| <--- |  Microservice 2 |
|  (Client)      |      | Middleware     |      |  (Client)       |
+----------------+      +----------------+      +----------------+

Legend:
- Microservices request tokens from Authentication Service
- Microservices validate tokens locally using middleware
- Authentication Service signs tokens with private key
- Public key distributed to services for verification

Components

Authentication Service

Node.js/Java/Spring Boot (any scalable backend)

Issue signed JWT tokens to services and provide token introspection

Token Validation Middleware

Library in each microservice (e.g., JWT verification library)

Verify token signature, expiration, and claims on each request

Key Management

Vault or KMS (e.g., HashiCorp Vault, AWS KMS)

Securely store and rotate signing keys

Service Registry

Consul/Eureka/Etcd

Allow services to discover Authentication Service endpoints

Revocation Cache

Redis or in-memory cache

Store revoked token IDs for quick lookup

Logging and Monitoring

ELK Stack, Prometheus, Grafana

Track authentication requests, failures, and system health

Request Flow

1. 1. Microservice requests a token from Authentication Service using its credentials.

2. 2. Authentication Service authenticates the service and issues a signed JWT token with a short expiry.

3. 3. Microservice includes the JWT token in requests to other microservices.

4. 4. Receiving microservice uses Token Validation Middleware to verify the token signature and expiry locally.

5. 5. Middleware checks the revocation cache to ensure token is not revoked.

6. 6. If token is valid, request proceeds; otherwise, it is rejected with an authentication error.

7. 7. Authentication Service periodically rotates signing keys and updates public keys distributed to services.

Database Schema

Entities: - ServiceCredentials: service_id (PK), secret, metadata - RevokedTokens: token_id (PK), revoked_at - SigningKeys: key_id (PK), public_key, private_key, created_at, expires_at Relationships: - ServiceCredentials used to authenticate services requesting tokens - RevokedTokens checked during token validation - SigningKeys used by Authentication Service to sign tokens and by services to verify tokens

Scaling Discussion

Bottlenecks

Authentication Service becomes a bottleneck under high token request load

Token validation latency if every request requires remote validation

Key management complexity with frequent key rotations

Revocation cache size and lookup latency

Network latency between services and Authentication Service

Solutions

Scale Authentication Service horizontally behind a load balancer

Use stateless JWT tokens so services can validate tokens locally without remote calls

Implement key rotation with overlapping keys and distribute public keys via service registry or config

Use fast in-memory cache (e.g., Redis) for revocation list with TTL to limit size

Use service mesh or sidecar proxies to handle authentication and reduce network overhead

Interview Tips

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

Explain why token-based authentication is suitable for service-to-service communication

Discuss trade-offs between JWT and opaque tokens

Highlight importance of short-lived tokens and revocation

Describe how local token validation reduces latency and load

Mention key management and secure storage as critical for security

Address scaling by horizontal service scaling and caching

Show awareness of real-world challenges like key rotation and token revocation