OAuth 2.0 for microservices - Scalability & System Analysis

Scalability Analysis - OAuth 2.0 for microservices

Growth Table: OAuth 2.0 for Microservices

Users	What Changes?
100 users	Single authorization server handles token issuance; microservices validate tokens locally or via introspection; low latency.
10,000 users	Authorization server load increases; token cache needed; microservices may use local token validation libraries; introspection calls optimized.
1,000,000 users	Authorization server becomes bottleneck; need horizontal scaling; token revocation and refresh token management complex; distributed cache for tokens; microservices use JWT validation to reduce introspection.
100,000,000 users	Massive authorization server cluster with load balancing; global token cache/CDN; token revocation via blacklist with distributed storage; microservices rely on stateless JWT validation; network bandwidth and latency critical.

First Bottleneck

The authorization server is the first bottleneck. It handles token issuance, validation (if introspection is used), and revocation. As user count and token requests grow, CPU and database load on this server increase, causing latency and failures.

Scaling Solutions

• Horizontal scaling: Run multiple authorization server instances behind a load balancer to distribute token requests.
• Token caching: Use distributed caches (e.g., Redis) to store token introspection results to reduce repeated DB calls.
• Stateless tokens: Use JWT access tokens with embedded claims and signature verification to avoid introspection calls.
• Token revocation: Implement token blacklist with efficient distributed storage or short-lived tokens with refresh tokens.
• Microservice validation: Microservices validate tokens locally using public keys to reduce network calls.
• CDN and geo-distribution: Deploy authorization servers and caches closer to users to reduce latency.

Back-of-Envelope Cost Analysis

• Assuming 1M users, each making 1 request per second -> 1M QPS token validations.
• Authorization server can handle ~5,000 QPS per instance -> need ~200 instances for token issuance/introspection.
• Using JWT reduces introspection calls by 90%, lowering load to ~100,000 QPS -> ~20 instances needed.
• Storage for token revocation lists depends on token lifetime; short-lived tokens reduce storage needs.
• Network bandwidth: 1M QPS x ~1KB token data = ~1GB/s bandwidth needed for token validation traffic.

Interview Tip

Start by identifying the main components: authorization server, microservices, token types. Discuss how token validation scales and where bottlenecks appear. Propose stateless tokens and caching to reduce load. Mention trade-offs like token revocation complexity. Always connect scaling steps to specific bottlenecks.

Self Check

Your authorization server handles 1,000 QPS token introspection. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Introduce stateless JWT tokens so microservices can validate tokens locally without introspection calls, reducing load on the authorization server.

Key Result

The authorization server is the first bottleneck as user and token validation requests grow; using stateless JWT tokens and caching reduces load and enables horizontal scaling.

Practice

1. What is the main purpose of using OAuth 2.0 in a microservices architecture?

easy

A. To allow microservices to securely share user permissions without sharing passwords

B. To encrypt all communication between microservices

C. To store user data centrally in one microservice

D. To replace HTTPS for secure communication

Solution

1. Step 1: Understand OAuth 2.0 role in microservices

   OAuth 2.0 is designed to delegate access without sharing user passwords, enabling secure permission sharing.

2. Step 2: Differentiate from other security methods

   OAuth 2.0 does not encrypt communication or replace HTTPS; it focuses on authorization, not data storage or transport security.

3. Final Answer:

   To allow microservices to securely share user permissions without sharing passwords -> Option A

4. Quick Check:

   OAuth 2.0 = Secure permission sharing [OK]

Hint: OAuth 2.0 is about permissions, not encryption or storage [OK]

Common Mistakes:

• Confusing OAuth 2.0 with encryption protocols
• Thinking OAuth 2.0 stores user data centrally
• Assuming OAuth 2.0 replaces HTTPS

2. Which of the following is the correct way to include an OAuth 2.0 access token in an HTTP request header?

easy

A. Auth-Token: <access_token>

B. Token: OAuth <access_token>

C. Authorization: Bearer <access_token>

D. Access: BearerToken <access_token>

Solution

1. Step 1: Recall OAuth 2.0 token header format

   The standard way to send an OAuth 2.0 token is using the Authorization header with the Bearer scheme.

2. Step 2: Verify header syntax

   Correct syntax is exactly "Authorization: Bearer <token>"; other options use incorrect header names or schemes.

3. Final Answer:

   Authorization: Bearer <access_token> -> Option C

4. Quick Check:

   OAuth token header = Authorization: Bearer [OK]

Hint: OAuth tokens go in Authorization header with Bearer prefix [OK]

Common Mistakes:

• Using wrong header names like Token or Auth-Token
• Missing the 'Bearer' keyword before the token
• Using incorrect capitalization or spacing

3. Given a microservice receiving a JWT access token, which step correctly validates the token before processing the request?

medium

A. Decrypt the token and store it in a database

B. Check token signature, verify expiration, and confirm required scopes

C. Send the token to the user service for validation every time

D. Ignore the token if the request comes from a trusted IP

Solution

1. Step 1: Understand JWT validation steps

   JWT tokens are validated by checking their signature, expiration time, and scopes to ensure authenticity and permission.

2. Step 2: Eliminate incorrect practices

   Decrypting JWT is incorrect because JWTs are signed, not encrypted; querying user service every time reduces scalability; trusting IP alone is insecure.

3. Final Answer:

   Check token signature, verify expiration, and confirm required scopes -> Option B

4. Quick Check:

   JWT validation = signature + expiry + scopes [OK]

Hint: Validate JWT by signature, expiry, and scopes locally [OK]

Common Mistakes:

• Trying to decrypt JWT instead of verifying signature
• Validating tokens by calling user service every request
• Trusting IP addresses instead of tokens

4. A microservice is failing to authenticate requests even though clients send valid OAuth 2.0 tokens. Which is the most likely cause?

medium

A. The microservice is not verifying the token signature correctly

B. The clients are sending tokens in the URL query parameters

C. The microservice is using HTTPS for communication

D. The tokens are expired but the microservice ignores expiration

Solution

1. Step 1: Analyze token verification failure

   If valid tokens are sent but authentication fails, incorrect signature verification is a common cause.

2. Step 2: Evaluate other options

   Sending tokens in URL is discouraged but may still work; HTTPS is required for security but not cause failure; ignoring expiration would allow some tokens through, not fail all.

3. Final Answer:

   The microservice is not verifying the token signature correctly -> Option A

4. Quick Check:

   Invalid signature verification = auth failure [OK]

Hint: Check token signature verification first when auth fails [OK]

Common Mistakes:

• Blaming HTTPS for authentication issues
• Assuming tokens in URL always cause failure
• Ignoring token expiration causes failure, not ignoring it

5. In a microservices system using OAuth 2.0, how can an API Gateway improve scalability and security when handling access tokens?

hard

A. By bypassing token validation to reduce latency

B. By storing all user passwords and tokens for microservices to access

C. By encrypting all tokens with a shared secret before sending to microservices

D. By centralizing token validation and forwarding only authorized requests to microservices

Solution

1. Step 1: Understand API Gateway role in OAuth 2.0

   The API Gateway can validate tokens centrally, so microservices do not need to validate tokens individually, improving performance and security.

2. Step 2: Eliminate incorrect options

   Storing passwords centrally is insecure; encrypting tokens unnecessarily adds complexity; bypassing validation reduces security and is unsafe.

3. Final Answer:

   By centralizing token validation and forwarding only authorized requests to microservices -> Option D

4. Quick Check:

   API Gateway = central token validation [OK]

Hint: Use API Gateway to validate tokens once for all microservices [OK]

Common Mistakes:

• Thinking API Gateway stores user passwords
• Assuming tokens must be encrypted again by gateway
• Skipping token validation to save time