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