Navigating OAuth 2.0 for System Design Interviews

Introduction

OAuth 2.0 is a widely used authorization protocol that enables secure, delegated access to resources in modern applications. In technical interviews, OAuth 2.0 questions test your understanding of authentication and authorization flows, critical for designing secure APIs and microservices. Whether it’s enabling third-party access or securing user data, OAuth 2.0 is a cornerstone of modern system design. This post explores OAuth 2.0’s core mechanics, its role in interviews, and how to apply it effectively in real-world systems.

Core Concepts

OAuth 2.0 is an authorization framework that allows a client (e.g., a mobile app) to access a user’s resources (e.g., Google Drive files) without sharing credentials. It delegates access through 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).
• Authorization Server: Issues access tokens after user consent (e.g., Google’s auth server).
• Resource Server: Hosts the protected resources (e.g., Google Drive API).
• Access Token: A short-lived token granting access to specific resources.
• Refresh Token: A longer-lived token used to obtain new access tokens.

OAuth 2.0 Grant Types (Flows)

• Authorization Code Grant: Used by web apps. The client redirects the user to the authorization server, which issues an authorization code exchanged for an access token. Secure and common for server-side apps.
• Implicit Grant: Simplified for client-side apps (e.g., SPAs). The access token is returned directly via URL redirect. Less secure, deprecated in OAuth 2.1.
• Client Credentials Grant: For machine-to-machine communication, where the client authenticates itself to access resources (e.g., API-to-API calls).
• Resource Owner Password Credentials: Uses user credentials directly (less common, insecure, used in trusted apps).
• Refresh Token Grant: Uses a refresh token to obtain a new access token without re-authenticating the user.

Flow Example: Authorization Code Grant

1. User clicks “Login with Google” in a client app.
2. Client redirects user to Google’s authorization server, where they consent to access.
3. Authorization server returns an authorization code to the client via redirect.
4. Client exchanges the code for an access token (and optionally a refresh token) via a secure backend call.
5. Client uses the access token to access the resource server (e.g., Google Drive API).

Diagram: OAuth 2.0 Authorization Code Flow

[User] --> [Client App] --> [Redirect to Auth Server]
                          |
                          v
[User Consent] <-- [Authorization Server] --> [Authorization Code]
                          |
                          v
[Client Backend] --> [Exchange Code for Access Token] --> [Access Token]
                          |
                          v
[Client] --> [Resource Server] --> [Access Resources]

Key Considerations

• Token Lifespan: Access tokens are short-lived (e.g., 1 hour) for security; refresh tokens last longer but require secure storage.
• Scopes: Define specific permissions (e.g., “read profile” or “write files”).
• Security: Use HTTPS, validate redirect URIs, and protect refresh tokens to prevent attacks like token theft.

Interview Angle

OAuth 2.0 is a frequent topic in system design interviews, especially for secure API or microservices design. Common questions include:

• Explain how OAuth 2.0 works in a web application. Tip: Walk through the Authorization Code Grant, emphasizing user consent, token exchange, and security. Use a real-world example like “Login with Google.”
• What’s the difference between OAuth 2.0 and OpenID Connect? Approach: Explain that OAuth 2.0 is for authorization (access to resources), while OpenID Connect adds authentication (user identity) on top of OAuth 2.0.
• How would you secure an OAuth 2.0 flow in a mobile app? Answer: Use Authorization Code Grant with PKCE (Proof Key for Code Exchange) to prevent code-interception attacks. Store refresh tokens securely (e.g., in a secure keychain).
• Follow-Up: “What happens if an access token is compromised?” Solution: Discuss short-lived tokens, scope restrictions, and token revocation. Suggest monitoring for unusual activity and using refresh tokens to limit exposure.

Pitfalls to Avoid:

• Confusing OAuth 2.0 (authorization) with authentication. Clarify that OpenID Connect handles authentication.
• Overlooking security practices like PKCE or HTTPS, which are critical for mobile or client-side apps.
• Proposing insecure flows like Implicit Grant for modern apps, as it’s deprecated.

Real-World Use Cases

• Google APIs: Uses OAuth 2.0 to allow apps like Notion or Zapier to access Gmail or Drive data with user consent.
• GitHub: Employs OAuth 2.0 for third-party apps to access repository data, using scopes to limit permissions.
• Slack: Integrates OAuth 2.0 for bot integrations, allowing secure access to workspace messages or channels.
• Spotify: Uses OAuth 2.0 to let apps access user playlists or playback controls, leveraging refresh tokens for seamless user experiences.

Summary

• OAuth 2.0: An authorization protocol for secure, delegated access to resources using tokens.
• Key Flows: Authorization Code (web apps), Client Credentials (machine-to-machine), and Refresh Token for token renewal.
• Interview Prep: Master the Authorization Code flow, security practices (e.g., PKCE), and differences from OpenID Connect.
• Real-World Impact: Powers secure integrations in Google, GitHub, Slack, and Spotify, enabling third-party access.
• Key Insight: OAuth 2.0 balances security and usability but requires careful handling of tokens and scopes to prevent vulnerabilities.

By understanding OAuth 2.0’s flows and security considerations, you’ll be well-prepared to design secure systems and ace system design interviews.