Bird
Raised Fist0
Microservicessystem_design~25 mins

OAuth 2.0 for microservices - System Design Exercise

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
Design: OAuth 2.0 Authorization for Microservices
Design covers OAuth 2.0 authorization server, token issuance, validation, and integration with microservices. Out of scope: user interface design, detailed user management, and third-party identity providers.
Functional Requirements
FR1: Allow users to authenticate and authorize access to multiple microservices securely.
FR2: Support token-based authentication using OAuth 2.0 standard.
FR3: Enable microservices to validate access tokens efficiently without contacting the authorization server on every request.
FR4: Support scopes and roles to restrict access to specific microservice APIs.
FR5: Allow token refresh without requiring user re-login.
FR6: Ensure secure communication between microservices and the authorization server.
FR7: Handle token revocation and expiration properly.
Non-Functional Requirements
NFR1: System must handle 10,000 concurrent users with low latency (p99 < 150ms for token validation).
NFR2: Authorization server availability must be 99.9% uptime.
NFR3: Microservices should not become bottlenecks due to authentication overhead.
NFR4: Tokens should have a limited lifetime (e.g., 1 hour) with refresh tokens valid for 7 days.
NFR5: Use industry-standard OAuth 2.0 flows suitable for microservices architecture.
Think Before You Design
Questions to Ask
❓ Question 1
❓ Question 2
❓ Question 3
❓ Question 4
❓ Question 5
❓ Question 6
Key Components
Authorization Server (OAuth 2.0 compliant)
Resource Servers (microservices)
API Gateway or Authentication Proxy
Token Store or Introspection Endpoint
User Authentication Service
Refresh Token Mechanism
Design Patterns
JWT (JSON Web Token) for stateless token validation
Token Introspection for opaque tokens
API Gateway as centralized authentication enforcement
Refresh Token rotation for security
Scope-based and role-based access control
Reference Architecture
  +-------------+       +-------------------+       +----------------+
  |             |       |                   |       |                |
  |   Client    +------>+ Authorization     +------>+ Token Store or  |
  |  (User App) |       | Server (AuthN/AuthZ)|     | Introspection   |
  +-------------+       +-------------------+       +----------------+
         |                        |                          |
         |                        |                          |
         |                        |                          |
         v                        v                          v
  +-------------+         +----------------+         +----------------+
  |             |         |                |         |                |
  | API Gateway +-------->+ Microservices  +<------->+ User Service   |
  | (Auth Proxy)|         | (Resource      |         |                |
  +-------------+         | Servers)       |         +----------------+
                          +----------------+
Components
Authorization Server
OAuth 2.0 compliant server (e.g., Keycloak, Auth0, custom)
Handles user authentication, issues access and refresh tokens, manages scopes and roles.
API Gateway
Nginx, Kong, or custom gateway
Central entry point that validates tokens before forwarding requests to microservices.
Microservices (Resource Servers)
Any microservice framework (Spring Boot, Node.js, etc.)
Provide business functionality and enforce authorization based on token scopes.
Token Store / Introspection Endpoint
In-memory cache or database for opaque tokens; introspection API
Allows microservices or gateway to validate opaque tokens by querying authorization server.
User Service
User database and authentication backend
Manages user credentials and profile data.
Request Flow
1. 1. Client requests authorization from Authorization Server using OAuth 2.0 flow (e.g., Authorization Code).
2. 2. Authorization Server authenticates user and issues access token (JWT or opaque) and refresh token.
3. 3. Client sends access token with API requests to API Gateway.
4. 4. API Gateway validates token locally if JWT or calls introspection endpoint if opaque.
5. 5. If token is valid and scopes allow, API Gateway forwards request to appropriate microservice.
6. 6. Microservice optionally validates token claims and enforces fine-grained access control.
7. 7. If access token expires, client uses refresh token to get a new access token from Authorization Server.
8. 8. Authorization Server supports token revocation and expiration to maintain security.
Database Schema
Entities: - User: id (PK), username, password_hash, email - ClientApp: id (PK), client_id, client_secret, redirect_uris - AccessToken: token_id (PK), user_id (FK), client_id (FK), scopes, expiry, token_type (JWT/opaque) - RefreshToken: token_id (PK), user_id (FK), client_id (FK), expiry - Scope: scope_name (PK), description - Role: role_name (PK), description Relationships: - User has many AccessTokens and RefreshTokens - ClientApp issues tokens to Users - AccessTokens have many Scopes - Users have Roles that map to Scopes for authorization
Scaling Discussion
Bottlenecks
Authorization Server becomes a bottleneck under high token issuance or introspection requests.
API Gateway latency increases due to token validation overhead.
Token revocation and refresh token management complexity grows with user base.
Microservices may face overhead if they validate tokens on every request.
Solutions
Use JWT tokens to enable stateless token validation at API Gateway and microservices, reducing calls to Authorization Server.
Cache token introspection results with short TTL to reduce load on Authorization Server.
Scale Authorization Server horizontally with load balancers.
Implement refresh token rotation and secure storage to reduce risk and complexity.
Use API Gateway to centralize authentication and offload microservices.
Use asynchronous event-driven mechanisms to propagate token revocation information to microservices.
Interview Tips
Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing components and data flow, 10 minutes discussing scaling and security considerations, and 5 minutes summarizing.
Explain OAuth 2.0 flows suitable for microservices (Authorization Code with PKCE, Client Credentials).
Discuss trade-offs between JWT and opaque tokens for validation and security.
Highlight importance of scopes and roles for fine-grained access control.
Describe how API Gateway can centralize authentication to reduce complexity.
Address token revocation and refresh token security best practices.
Discuss scaling strategies to maintain low latency and high availability.

Practice

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