OAuth 2.0 flow in HLD - System Design Exercise

Design: OAuth 2.0 Authorization System

Design covers OAuth 2.0 Authorization Code flow including user authentication, authorization server, resource server, and client interactions. Out of scope: detailed user authentication methods, UI design, and other OAuth flows like implicit or device code.

Functional Requirements

FR1: Allow users to authorize third-party applications to access their data without sharing passwords

FR2: Support Authorization Code Grant flow for web applications

FR3: Support Access Token issuance with expiration

FR4: Allow token refresh without user re-login

FR5: Securely authenticate users and clients

FR6: Provide scopes to limit access permissions

FR7: Support revocation of tokens

Non-Functional Requirements

NFR1: Handle up to 10,000 concurrent authorization requests

NFR2: API response latency p99 under 200ms

NFR3: Availability target 99.9% uptime

NFR4: Secure storage of client secrets and tokens

NFR5: Prevent common attacks like CSRF, token leakage

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

❓ Question 6

❓ Question 7

Key Components

Authorization Server

Resource Server

Client Application

User Agent (browser)

Token Storage (database or cache)

Secure Authentication Service

Design Patterns

Authorization Code Grant Flow

Token-based Authentication

Refresh Token Pattern

State Parameter for CSRF Protection

Scope-based Access Control

Reference Architecture

User Agent (Browser)
      |
      | 1. User requests access to Client Application
      v
Client Application <-----> Authorization Server
      |                         |
      | 2. Redirect user to Authorization Server for login and consent
      |                         |
      |<------------------------|
      | 3. Authorization Server authenticates user and asks consent
      |                         |
      | 4. Authorization Server redirects back with Authorization Code
      |                         |
      |------------------------->
      | 5. Client Application exchanges Authorization Code for Access Token
      |                         |
      |<-------------------------|
      | 6. Client uses Access Token to access Resource Server
      |                         |
      |------------------------->
      |                         v
Resource Server (API) verifies Access Token and serves data

Components

Authorization Server

OAuth 2.0 compliant server (e.g., Keycloak, Auth0, custom)

Authenticate users, obtain consent, issue authorization codes and tokens

Client Application

Web or mobile app

Requests user authorization and uses tokens to access protected resources

User Agent (Browser)

Web browser

Facilitates user interaction for login and consent

Resource Server

API server

Validates access tokens and serves protected user data

Token Storage

Secure database or cache (e.g., Redis, PostgreSQL)

Store issued tokens, refresh tokens, and client credentials securely

Request Flow

1. User opens Client Application and requests access to protected resource

2. Client redirects User Agent to Authorization Server login and consent page with client_id, redirect_uri, state, and scope

3. User authenticates and grants consent on Authorization Server

4. Authorization Server redirects User Agent back to Client with Authorization Code and state

5. Client verifies state to prevent CSRF

6. Client sends Authorization Code, client_id, and client_secret to Authorization Server token endpoint

7. Authorization Server validates code and client credentials, then issues Access Token and Refresh Token

8. Client stores tokens securely and uses Access Token in API requests to Resource Server

9. Resource Server validates Access Token and returns requested data

10. When Access Token expires, Client uses Refresh Token to get a new Access Token from Authorization Server

Database Schema

Entities: - User: id, username, password_hash, email - Client: client_id, client_secret_hash, redirect_uris, scopes - AuthorizationCode: code, user_id, client_id, redirect_uri, scope, expiration_time - AccessToken: token, user_id, client_id, scope, expiration_time - RefreshToken: token, user_id, client_id, scope, expiration_time Relationships: - User 1:N AuthorizationCode - Client 1:N AuthorizationCode - User 1:N AccessToken - Client 1:N AccessToken - User 1:N RefreshToken - Client 1:N RefreshToken All tokens and secrets stored hashed or encrypted for security.

Scaling Discussion

Bottlenecks

Authorization Server CPU and memory under high concurrent login and token issuance

Database bottleneck for token storage and validation

Latency in token validation causing slow API responses

Handling token revocation and refresh at scale

Preventing abuse and attacks like brute force or token replay

Solutions

Use horizontal scaling with load balancers for Authorization Server

Implement caching (e.g., Redis) for token validation to reduce DB hits

Use stateless JWT tokens with signature verification to reduce DB dependency

Implement rate limiting and anomaly detection to prevent abuse

Use asynchronous token revocation propagation and short token lifetimes

Interview Tips

Time: Spend 10 minutes clarifying requirements and constraints, 20 minutes designing the architecture and data flow, 10 minutes discussing scaling and security, 5 minutes summarizing and answering questions.

Explain OAuth 2.0 Authorization Code flow clearly with user and client roles

Highlight security measures like state parameter and token storage

Discuss token types, expiration, and refresh mechanisms

Show understanding of scalability challenges and caching

Mention common attacks and mitigation strategies

Practice

1. What is the main purpose of the OAuth 2.0 Authorization Code flow?

easy

A. To replace user authentication with biometric data

B. To store user passwords safely on the server

C. To allow apps to access user data securely without sharing passwords

D. To encrypt all user data before sending it

Solution

1. Step 1: Understand OAuth 2.0 Authorization Code flow

   This flow lets apps get permission to access user data without needing the user's password directly.

2. Step 2: Identify the main goal

   The goal is to keep user credentials safe while allowing apps to act on behalf of the user.

3. Final Answer:

   To allow apps to access user data securely without sharing passwords -> Option C

4. Quick Check:

   OAuth 2.0 Authorization Code flow = Secure app access without passwords [OK]

Hint: Remember: OAuth avoids sharing passwords directly [OK]

Common Mistakes:

• Confusing OAuth with password storage
• Thinking OAuth encrypts all user data
• Assuming OAuth replaces authentication methods

2. Which of the following is the correct sequence in the OAuth 2.0 Authorization Code flow?

easy

A. User logs in -> App receives access token -> App requests authorization code

B. App sends password -> User grants access -> App receives token

C. App directly receives access token -> User logs in -> Access granted

D. User logs in -> App gets authorization code -> App exchanges code for access token

Solution

1. Step 1: Recall the OAuth 2.0 Authorization Code flow steps

   User logs in and authorizes the app, which then receives an authorization code.

2. Step 2: Understand token exchange

   The app exchanges the authorization code for an access token to access user data.

3. Final Answer:

   User logs in -> App gets authorization code -> App exchanges code for access token -> Option D

4. Quick Check:

   Authorization Code flow sequence = Login, code, token [OK]

Hint: Authorization code comes before access token [OK]

Common Mistakes:

• Thinking app gets token before authorization code
• Confusing password sending with OAuth flow
• Mixing order of login and token receipt

3. Given this OAuth 2.0 flow snippet, what is the expected output after exchanging the authorization code?

POST /token
Headers: Content-Type: application/x-www-form-urlencoded
Body: grant_type=authorization_code&code=abc123&redirect_uri=https://app.com/callback&client_id=client123&client_secret=secretXYZ

Response:
{
  "access_token": "token456",
  "token_type": "Bearer",
  "expires_in": 3600
}

medium

A. An access token 'token456' valid for 3600 seconds

B. An error because client_secret is missing

C. A refresh token instead of access token

D. No token, only a confirmation message

Solution

1. Step 1: Analyze the token request

   The app sends a POST request with grant_type authorization_code and includes the code and client credentials.

2. Step 2: Interpret the response

   The response contains an access_token 'token456', token_type 'Bearer', and expires_in 3600 seconds, meaning the token is valid for one hour.

3. Final Answer:

   An access token 'token456' valid for 3600 seconds -> Option A

4. Quick Check:

   Token response includes access_token and expiry [OK]

Hint: Token response includes access_token and expiry time [OK]

Common Mistakes:

• Expecting refresh token instead of access token
• Missing client_secret causes error
• Confusing confirmation message with token response

4. A developer implements OAuth 2.0 Authorization Code flow but the app never receives an access token after exchanging the code. What is the most likely cause?

medium

A. The app forgot to include the client_id in the authorization request

B. The redirect URI used in the token request does not match the one registered

C. The user did not enter their password correctly

D. The access token expired before the request

Solution

1. Step 1: Identify common OAuth token exchange errors

   One frequent error is a mismatch in redirect URI between authorization and token requests.

2. Step 2: Understand impact of redirect URI mismatch

   If the redirect URI differs, the authorization server rejects the token request, so no access token is returned.

3. Final Answer:

   The redirect URI used in the token request does not match the one registered -> Option B

4. Quick Check:

   Redirect URI mismatch blocks token issuance [OK]

Hint: Check redirect URI matches exactly in all requests [OK]

Common Mistakes:

• Blaming user password errors for token issues
• Ignoring client_id in authorization request
• Assuming token expires before it is issued

5. You are designing a system that uses OAuth 2.0 Authorization Code flow for a mobile app and a web app. Which approach best secures the access tokens and refresh tokens?

hard

A. Use Authorization Code flow with PKCE for the mobile app and standard Authorization Code flow for the web app

B. Use Implicit flow for both apps to simplify token handling

C. Store access tokens in local storage for both apps to allow easy access

D. Send access tokens directly in URL query parameters for both apps

Solution

1. Step 1: Understand security needs for mobile and web apps

   Mobile apps cannot keep client secrets safe, so PKCE (Proof Key for Code Exchange) enhances security for Authorization Code flow.

2. Step 2: Choose best practices for token storage and flow

   Web apps can use standard Authorization Code flow with client secret. Implicit flow is deprecated due to security risks. Storing tokens in local storage or URLs exposes them to attacks.

3. Final Answer:

   Use Authorization Code flow with PKCE for the mobile app and standard Authorization Code flow for the web app -> Option A

4. Quick Check:

   PKCE secures mobile OAuth; standard flow suits web apps [OK]

Hint: Use PKCE for mobile apps, standard flow for web apps [OK]

Common Mistakes:

• Using Implicit flow despite security risks
• Storing tokens insecurely in local storage
• Passing tokens in URL parameters