OAuth 2.0 flow in HLD - System Design Guide

Problem Statement

When users want to access multiple services, asking them to share their passwords with every service creates security risks and poor user experience. Without a standard way to delegate access, services either store sensitive credentials or force users to create new accounts everywhere.

Solution

OAuth 2.0 flow allows users to grant limited access to their resources on one service to another service without sharing their passwords. It works by issuing tokens after user consent, which the requesting service uses to access resources securely and temporarily.

Architecture

┌───────────────┐       Authorization Code       ┌───────────────┐
│               │ ─────────────────────────────> │               │
│   Client App  │                                │ Authorization  │
│               │ <───────────────────────────── │    Server     │
└───────────────┘          Authorization Code    └───────────────┘
       │                                              │
       │                                              │
       │          Access Token Request                 │
       │ ───────────────────────────────────────────> │
       │                                              │
       │ <────────────────────────────────────────── │
       │               Access Token                    │
       │                                              │
       │                                              │
       │          Resource Request with Token         │
       │ ───────────────────────────────────────────> │
       │                                              │
       │ <────────────────────────────────────────── │
       │             Protected Resource                │
       ▼                                              ▼

This diagram shows the OAuth 2.0 Authorization Code flow where the client app requests an authorization code from the authorization server, exchanges it for an access token, and then uses the token to access protected resources.

Trade-offs

✓ Pros

→

Users do not share passwords with third-party apps, improving security.

→

Access tokens can be limited in scope and time, reducing risk if leaked.

→

Standardized flow supported by many platforms and libraries.

→

Supports delegated access without exposing user credentials.

✗ Cons

→

Requires multiple network calls, adding latency to the authentication process.

→

Implementation complexity is higher than simple password sharing.

→

Token management and revocation require careful handling to avoid misuse.

Use OAuth 2.0 when your system needs to allow third-party apps limited access to user data without sharing passwords, especially at scale with many users and services.

Avoid OAuth 2.0 for simple internal applications with no third-party access or when user base is very small (under 100 users) and simpler authentication suffices.

Real World Examples

Google

Google uses OAuth 2.0 to let users grant third-party apps access to their Google Drive files without sharing their Google passwords.

Facebook

Facebook uses OAuth 2.0 to allow apps to post on users' behalf or access profile information securely.

GitHub

GitHub uses OAuth 2.0 to enable developers to authorize external tools to access repositories and user data without exposing credentials.

Alternatives

API Keys

API keys are static tokens given to clients without user consent flow or token expiration.

Use when: Use API keys for simple service-to-service authentication without user delegation.

OpenID Connect

OpenID Connect builds on OAuth 2.0 to add user identity verification and profile information.

Use when: Choose OpenID Connect when you need both authentication and authorization with user identity.

SAML

SAML uses XML-based assertions for single sign-on, mainly in enterprise environments.

Use when: Use SAML for enterprise single sign-on where legacy systems require it.

Summary

OAuth 2.0 flow prevents password sharing by issuing limited access tokens after user consent.

It uses an authorization server to grant tokens that clients use to access protected resources securely.

This flow is widely adopted for delegated access across many popular platforms.