OAuth 2.0 for microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

OAuth 2.0 Token Flow in Microservices

Consider a microservices system where a client app needs to access multiple services securely using OAuth 2.0. Which component is responsible for issuing access tokens that microservices validate?

A Client app issues tokens; Resource Servers validate tokens.

B Resource Servers issue tokens; Authorization Server validates tokens.

C Resource Servers issue and validate tokens internally without Authorization Server.

D Authorization Server issues tokens; Resource Servers validate tokens.

💡 Hint

Think about the OAuth 2.0 roles: who grants tokens and who protects resources.

In OAuth 2.0, the Authorization Server issues access tokens. Resource Servers (microservices) validate these tokens to allow or deny access.

❓ scaling

intermediate

Scaling Token Validation in Microservices

In a microservices architecture using OAuth 2.0, what is the best approach to efficiently validate access tokens across many services?

A Microservices cache token introspection results locally with expiration times.

B Each microservice calls the Authorization Server synchronously for every token validation.

C Microservices ignore token validation and trust the client app.

D Microservices validate tokens by decrypting JWTs without any caching.

💡 Hint

Consider reducing network calls while keeping token validation secure and fresh.

Caching token introspection results locally reduces latency and load on the Authorization Server while maintaining security by respecting token expiration.

❓ tradeoff

advanced

Choosing Between JWT and Opaque Tokens

Which is a key tradeoff when choosing JWT tokens over opaque tokens for OAuth 2.0 in microservices?

A Opaque tokens are always smaller and faster to validate than JWT tokens.

B JWT tokens require synchronous calls to Authorization Server for every request.

C JWT tokens allow stateless validation but can be large and harder to revoke immediately.

D Opaque tokens are self-contained and allow stateless validation without contacting Authorization Server.

💡 Hint

Think about token size, validation method, and revocation challenges.

JWT tokens carry claims and can be validated without contacting the Authorization Server, but revoking them immediately is difficult. Opaque tokens require introspection calls but can be revoked instantly.

🧠 Conceptual

advanced

Role of Refresh Tokens in Microservices

In OAuth 2.0 for microservices, what is the main purpose of a refresh token?

A To obtain new access tokens without requiring the user to re-authenticate.

B To directly access protected resources without an access token.

C To validate access tokens at the Resource Server level.

D To revoke access tokens when a user logs out.

💡 Hint

Think about how long access tokens last and user experience.

Refresh tokens allow clients to get new access tokens after the old ones expire without asking the user to log in again, improving usability and security.

❓ estimation

expert

Estimating Token Validation Load

A microservices system has 100 services, each receiving 1000 requests per second. Each request requires validating an OAuth 2.0 token. If each token introspection call to the Authorization Server takes 10ms, what is the minimum number of Authorization Server instances needed to handle token introspection without queuing delays, assuming each instance can handle 1000 introspections per second?

A At least 50 instances to handle 50,000 introspections per second.

B At least 100 instances to handle 100,000 introspections per second.

C At least 1 instance since caching reduces load significantly.

D At least 10 instances to handle 100,000 introspections per second.

💡 Hint

Calculate total introspection calls per second and divide by capacity per instance.

Total requests = 100 services * 1000 requests = 100,000 introspections per second. Each instance handles 1000 introspections per second, so 100,000 / 1000 = 100 instances needed.

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