OAuth 2.0 flow in HLD - Deep Dive

Overview - OAuth 2.0 flow

What is it?

OAuth 2.0 flow is a way for apps to get permission to access user data from another service without asking for the user's password. It lets users approve limited access to their information on one site, to be used by another app. This flow involves exchanging tokens that represent permission instead of sharing sensitive login details.

Why it matters

Without OAuth 2.0, apps would need to ask users for their passwords directly, which is risky and unsafe. OAuth 2.0 protects user privacy and security by limiting what apps can do and by avoiding password sharing. It also makes it easier for users to control and revoke access, improving trust and safety on the internet.

Where it fits

Before learning OAuth 2.0 flow, you should understand basic web concepts like HTTP requests, APIs, and authentication. After mastering OAuth 2.0, you can explore related topics like OpenID Connect for identity, API security best practices, and token management strategies.

Mental Model

Core Idea

OAuth 2.0 flow is a secure handshake where a user grants an app a special ticket (token) to access their data without sharing their password.

Think of it like...

Imagine you want to borrow a book from a library. Instead of giving the librarian your house keys (password), you get a library card (token) that lets you borrow books safely. If you lose the card, you can cancel it without changing your house locks.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│    User       │       │    Client     │       │ Authorization │
│ (Resource     │       │   (App)       │       │    Server     │
│  Owner)       │       │               │       │               │
└──────┬────────┘       └──────┬────────┘       └──────┬────────┘
       │                       │                       │       
       │ 1. User requests app  │                       │       
       │    access            │                       │       
       │────────────────────▶ │                       │       
       │                       │ 2. App redirects user │       
       │                       │    to authorization   │       
       │                       │    server             │       
       │                       │────────────────────▶  │       
       │                       │                       │       
       │                       │ 3. User grants access  │       
       │                       │    and gets code      │       
       │                       │◀────────────────────  │       
       │ 4. User sends code to  │                       │       
       │    app                │                       │       
       │◀────────────────────  │                       │       
       │                       │ 5. App exchanges code  │       
       │                       │    for access token   │       
       │                       │────────────────────▶  │       
       │                       │                       │       
       │                       │ 6. Authorization server│       
       │                       │    returns token      │       
       │                       │◀────────────────────  │       
       │                       │                       │       
       │ 7. App uses token to   │                       │       
       │    access user data   │                       │       
       │────────────────────▶ │                       │       
       ▼                       ▼                       ▼       

Build-Up - 7 Steps

1

Foundation

Understanding OAuth basics

Concept: Learn what OAuth 2.0 is and why it uses tokens instead of passwords.

OAuth 2.0 is a protocol that lets apps access user data on another service safely. Instead of sharing passwords, apps get tokens that represent permission. These tokens limit what the app can do and protect user privacy.

Result

You understand OAuth 2.0 is about secure permission delegation using tokens.

Understanding that OAuth replaces password sharing with tokens is key to grasping why it improves security and user control.

2

Foundation

Roles in OAuth 2.0 flow

Concept: Identify the main players: Resource Owner, Client, Authorization Server, and Resource Server.

Resource Owner is the user who owns data. Client is the app requesting access. Authorization Server issues tokens after user approval. Resource Server holds the data and accepts tokens to allow access.

Result

You can name and describe the four main roles in OAuth 2.0.

Knowing these roles helps you understand how responsibilities are divided and why OAuth is secure.

3

Intermediate

Authorization Code flow explained

🤔Before reading on: do you think the app gets the access token directly from the user or from the authorization server? Commit to your answer.

Concept: Learn the step-by-step process of the Authorization Code flow, the most common OAuth 2.0 flow.

1. User tries to use the app. 2. App redirects user to Authorization Server. 3. User logs in and approves access. 4. Authorization Server sends a code to the app. 5. App sends code to Authorization Server. 6. Authorization Server returns an access token. 7. App uses token to access user data from Resource Server.

Result

You understand how the app securely obtains an access token without seeing the user's password.

Knowing the code exchange step prevents exposing tokens in URLs and improves security.

4

Intermediate

Access and Refresh tokens

🤔Before reading on: do you think access tokens last forever or expire? Commit to your answer.

Concept: Understand the difference between short-lived access tokens and long-lived refresh tokens.

Access tokens let apps access data but expire quickly to reduce risk. Refresh tokens let apps get new access tokens without bothering the user again. This balance keeps sessions secure and user-friendly.

Result

You can explain why tokens have different lifetimes and how refresh tokens improve usability.

Recognizing token lifetimes helps you design systems that balance security and convenience.

5

Intermediate

Scopes and permissions

Concept: Learn how OAuth uses scopes to limit what an app can do with a token.

Scopes are labels that define what data or actions an app can access. When users approve, they see these scopes. Apps can only do what scopes allow, protecting user data from overreach.

Result

You understand how scopes enforce fine-grained access control.

Knowing scopes prevents apps from having more access than users intended, enhancing privacy.

6

Advanced

Implicit and Client Credentials flows

🤔Before reading on: do you think public apps can keep secrets safely? Commit to your answer.

Concept: Explore alternative OAuth flows for different app types and trust levels.

Implicit flow is for apps like single-page apps that can't keep secrets; it gets tokens directly but is less secure. Client Credentials flow is for server-to-server communication without user involvement, using client secrets.

Result

You know when and why to use different OAuth flows based on app type and security needs.

Understanding flow differences helps you pick the right approach for your app's environment.

7

Expert

Security pitfalls and mitigation

🤔Before reading on: do you think OAuth tokens can be safely stored anywhere? Commit to your answer.

Concept: Learn common security risks in OAuth 2.0 and how to avoid them.

Risks include token leakage, CSRF attacks, and improper token storage. Mitigations involve using PKCE (Proof Key for Code Exchange), secure storage, HTTPS, and validating redirect URIs strictly.

Result

You can identify and prevent common OAuth security vulnerabilities.

Knowing these risks and protections is essential to building secure OAuth implementations in production.

Under the Hood

OAuth 2.0 works by redirecting the user's browser between the client app and the authorization server. The authorization server authenticates the user and issues a temporary code. The client exchanges this code for an access token via a secure back-channel. Tokens are cryptographically signed or opaque strings that the resource server validates before granting access. This separation of roles and token exchange prevents password exposure and limits token scope and lifetime.

Why designed this way?

OAuth was designed to solve the problem of password sharing between apps and services. Early methods required users to give their passwords to third-party apps, risking security. OAuth introduced token-based delegation to allow limited, revocable access. The design balances security, usability, and flexibility across many app types and devices.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│    User       │       │    Client     │       │ Authorization │
│ (Resource     │       │   (App)       │       │    Server     │
│  Owner)       │       │               │       │               │
└──────┬────────┘       └──────┬────────┘       └──────┬────────┘
       │                       │                       │       
       │ 1. User initiates      │                       │       
       │    authorization      │                       │       
       │────────────────────▶ │                       │       
       │                       │ 2. Redirect user to    │       
       │                       │    authorization       │       
       │                       │    server              │       
       │                       │────────────────────▶  │       
       │                       │                       │       
       │                       │ 3. User authenticates  │       
       │                       │    and approves       │       
       │                       │                       │       
       │                       │ 4. Authorization code  │       
       │                       │    sent to client     │       
       │                       │◀────────────────────  │       
       │ 5. Client sends code   │                       │       
       │    to authorization   │                       │       
       │    server             │                       │       
       │────────────────────▶ │                       │       
       │                       │ 6. Authorization server│       
       │                       │    validates and sends │       
       │                       │    access token       │       
       │                       │◀────────────────────  │       
       │ 7. Client uses token   │                       │       
       │    to access resource │                       │       
       │────────────────────▶ │                       │       
       ▼                       ▼                       ▼       

Myth Busters - 4 Common Misconceptions

Quick: Does OAuth 2.0 share user passwords with third-party apps? Commit to yes or no.

Common Belief: OAuth 2.0 requires apps to get the user's password to access data.

Reality: OAuth 2.0 never shares user passwords with apps; it uses tokens instead.

Why it matters: Believing this leads to insecure apps that ask for passwords, risking user accounts.

Quick: Do access tokens last forever? Commit to yes or no.

Common Belief: Access tokens are permanent and never expire.

Reality: Access tokens have limited lifetimes and expire to reduce security risks.

Why it matters: Thinking tokens last forever can cause apps to misuse expired tokens, leading to failures or security holes.

Quick: Can public apps safely store client secrets? Commit to yes or no.

Common Belief: Public apps like mobile or browser apps can keep client secrets safe.

Reality: Public apps cannot keep secrets safe because users can inspect app code or storage.

Why it matters: Assuming secrets are safe in public apps leads to token theft and unauthorized access.

Quick: Does OAuth 2.0 guarantee user identity? Commit to yes or no.

Common Belief: OAuth 2.0 confirms who the user is (identity).

Reality: OAuth 2.0 only authorizes access; it does not provide user identity information.

Why it matters: Confusing authorization with authentication can cause apps to trust unverified users, risking security.

Expert Zone

1

PKCE (Proof Key for Code Exchange) is critical for securing Authorization Code flow in public clients, preventing code interception attacks.

2

Token revocation and introspection endpoints allow dynamic control over token validity, which many implementations overlook.

3

The choice between opaque tokens and JWTs (JSON Web Tokens) affects validation complexity and security tradeoffs.

When NOT to use

OAuth 2.0 is not suitable for simple authentication alone; use OpenID Connect for identity. For internal microservices communication, consider mutual TLS or API keys instead. Avoid OAuth for apps that cannot securely handle tokens or redirects, like some IoT devices.

Production Patterns

In production, OAuth 2.0 is used with PKCE for mobile apps, refresh tokens for long sessions, and strict redirect URI validation. Many companies combine OAuth with OpenID Connect for login and use centralized authorization servers to manage tokens and scopes.

Connections

OpenID Connect

Builds on OAuth 2.0 by adding user identity verification.

Understanding OAuth 2.0 helps grasp OpenID Connect, which adds authentication on top of authorization.

API Gateway

OAuth tokens are often validated by API gateways to control access to backend services.

Knowing OAuth token flow clarifies how API gateways enforce security policies in distributed systems.

Library Card System

Similar pattern of delegation and controlled access in a physical system.

Recognizing delegation patterns across domains helps design secure, user-friendly access control systems.

Common Pitfalls

#1 Storing access tokens in local storage in browser apps.

Wrong approach:

localStorage.setItem('access_token', token);

Correct approach:

Use in-memory storage or secure HTTP-only cookies to store tokens.

Root cause:

Misunderstanding that local storage is vulnerable to cross-site scripting (XSS) attacks.

#2 Skipping redirect URI validation on the authorization server.

Wrong approach:

Accept any redirect URI sent by the client without checking.

Correct approach:

Strictly validate redirect URIs against a whitelist registered per client.

Root cause:

Assuming redirect URIs are safe without validation leads to token interception.

#3 Using Implicit flow for new apps despite security risks.

Wrong approach:

Implementing Implicit flow to get tokens directly in browser apps.

Correct approach:

Use Authorization Code flow with PKCE for browser and mobile apps.

Root cause:

Following outdated OAuth recommendations without updating to modern best practices.

Key Takeaways

OAuth 2.0 flow enables apps to access user data securely without sharing passwords by using tokens.

The Authorization Code flow is the most secure and common method, involving a code exchange between client and authorization server.

Tokens have scopes and lifetimes to limit access and improve security; refresh tokens help maintain sessions without bothering users.

Security best practices like PKCE, redirect URI validation, and secure token storage are essential to prevent attacks.

OAuth 2.0 focuses on authorization, not authentication; for identity, use OpenID Connect on top of OAuth.