Unraveling OAuth 2.0 for System Design Interviews

Introduction

OAuth 2.0 is a widely adopted authorization protocol that enables secure, delegated access to resources, making it a critical topic in technical interviews for roles involving secure APIs or microservices. It’s essential for building systems that integrate with third-party services or manage user access. This post explores OAuth 2.0’s core mechanics, its role in system design, and how to ace related interview questions.

Core Concepts

OAuth 2.0 is an authorization framework that allows a client (e.g., an app) to access a user’s resources on a server without sharing credentials. It delegates access via tokens, ensuring security and scalability.

Key Components

Resource Owner: The user who owns the data (e.g., a Google account holder).
Client: The application requesting access (e.g., a third-party app like a calendar tool).
Authorization Server: Issues access tokens after user approval (e.g., Google’s auth server).
Resource Server: Hosts the protected resources (e.g., Google’s API for calendar data).
Access Token: A short-lived token granting access to specific resources.
Refresh Token: A long-lived token to obtain new access tokens without re-authentication.

OAuth 2.0 Grant Types

Authorization Code: For web/server apps; the client redirects the user to the authorization server, which issues a code exchanged for an access token. Most secure and common.
Implicit: For browser-based apps; directly issues an access token (less secure, used in single-page apps).
Client Credentials: For machine-to-machine communication, where the client authenticates itself (e.g., server-to-server APIs).
Resource Owner Password Credentials: Uses user credentials directly (rare, less secure, used in trusted apps).
Device Code: For devices with limited input (e.g., smart TVs), where a code is displayed for user authentication elsewhere.

Workflow (Authorization Code Grant)

The client redirects the user to the authorization server.
The user authenticates and approves access.
The authorization server issues an authorization code to the client.
The client exchanges the code for an access token (and optionally a refresh token).
The client uses the access token to access the resource server.

Design Considerations

Token Security: Use short-lived access tokens and secure storage (e.g., HTTPS, encrypted vaults) to prevent leaks.
Scopes: Define granular permissions (e.g., “read:email” vs. “write:email”) to limit access.
Refresh Tokens: Rotate refresh tokens to enhance security and handle expiration gracefully.
Revocation: Support token revocation to handle compromised clients or user logout.
Rate Limiting: Apply limits on token issuance to prevent abuse.

Diagram: OAuth 2.0 Authorization Code Flow

[User] --> [Client] --> [Redirect to Auth Server]
                        [User Authenticates & Approves]
                        [Auth Server] --> [Authorization Code]
                        [Client] --> [Exchange Code for Access Token]
                        [Client] --> [Resource Server with Access Token]

Analogy

Think of OAuth 2.0 as a hotel keycard system. The guest (user) authorizes the front desk (authorization server) to give a keycard (access token) to a valet (client) for specific access (e.g., room entry). The keycard expires, and a master key (refresh token) can generate new ones, but only for approved actions.

Interview Angle

OAuth 2.0 is a common topic in system design interviews, especially for secure APIs or third-party integrations. Common questions include:

How would you design a secure API that integrates with a third-party service? Tip: Propose OAuth 2.0 with the authorization code grant for web apps, using HTTPS and scoped tokens. Discuss refresh tokens and revocation for security.
Explain the difference between OAuth 2.0 and OpenID Connect. Approach: Clarify that OAuth 2.0 is for authorization (access to resources), while OpenID Connect builds on OAuth for authentication (user identity). Use examples like Google Sign-In (OpenID Connect) vs. Google Calendar API access (OAuth 2.0).
How do you secure OAuth 2.0 access tokens? Answer: Suggest short-lived tokens, HTTPS for transport, and secure storage (e.g., in-memory or encrypted). Discuss token revocation and scope limiting to reduce risks.
Follow-Up: “What happens if a refresh token is compromised?” Solution: Propose immediate revocation, token rotation, and audit logs to detect misuse. Suggest client authentication for refresh token requests to add security.

Pitfalls to Avoid:

Confusing OAuth 2.0 (authorization) with authentication; clarify its role vs. OpenID Connect.
Ignoring token security, such as storing tokens in plain text or using insecure channels.
Overlooking grant type suitability; match the grant to the use case (e.g., authorization code for web apps, client credentials for server-to-server).

Real-World Use Cases

Google APIs: Use OAuth 2.0 for apps like Gmail or Drive, allowing third-party access (e.g., email clients) with scoped tokens.
GitHub: Employs OAuth 2.0 for authorizing developer tools to access repositories or user data securely.
Spotify: Uses OAuth 2.0 to let apps access playlists or user profiles, leveraging the authorization code flow for web integrations.
Slack: Integrates with third-party apps via OAuth 2.0, enabling bots or workflows with fine-grained permissions.

Summary

OAuth 2.0: An authorization protocol for secure, delegated access to resources using tokens and grant types.
Key Mechanics: Authorization code flow for web apps, refresh tokens for longevity, and scopes for granular access.
Interview Prep: Focus on grant types, token security, and OAuth vs. OpenID Connect for secure API designs.
Real-World Impact: Powers Google, GitHub, and Spotify for secure third-party integrations.
Key Insight: OAuth 2.0 ensures secure access but requires careful token management and grant selection to balance security and usability.

By mastering OAuth 2.0, you’ll be ready to design secure, scalable systems and confidently tackle system design interviews.