OAuth 2.0
A delegation framework that lets users grant third-party applications limited access to their resources without sharing credentials.
OAuth 2.0 is an authorization delegation protocol (RFC 6749) that separates the roles of resource owner (user), client (third-party app), authorization server (issues tokens), and resource server (holds data). The user authenticates with the authorization server and grants consent; the client receives an access token to call APIs on the user's behalf. The key insight is that the user never shares their password with the third-party app. OAuth 2.0 defines multiple grant types -- authorization code (most secure for web apps), client credentials (machine-to-machine), and others -- to handle different scenarios.
Security Model
OAuth 2.0 security relies on TLS for transport, PKCE for authorization code protection, state parameters for CSRF prevention, exact redirect URI matching, and short-lived access tokens with refresh token rotation. The authorization server is the trust anchor -- if compromised, all downstream services are affected. Client authentication strength varies by client type (confidential vs public).
Implementation
high complexityUser Experience
Users see a redirect to the identity provider, authenticate (if not already signed in), review a consent screen listing requested permissions, and are redirected back to the application. The redirect flow can feel disruptive but builds trust by showing explicit permission grants. Social login buttons ('Sign in with Google') abstract much of this complexity.
Platform Examples
Massive OAuth 2.0 provider with 200+ API scopes. Uses authorization code + PKCE. Supports incremental authorization (requesting additional scopes over time). Token lifetimes: 1 hour access, long-lived refresh.
GitHub
OAuth 2.0 for app integrations with fine-grained repository-level scopes. Supports OAuth Apps and GitHub Apps (recommended) with installation-level tokens.
Spotify
Authorization Code flow for user-facing apps, Client Credentials for server-to-server catalog access. Scopes like user-read-private, playlist-modify-public.
Coinbase
OAuth 2.0 for third-party apps accessing user accounts. Scopes include wallet:accounts:read, wallet:transactions:send. Uses refresh token rotation.
Tradeoffs
Strengths
- Users never share credentials with third-party apps
- Fine-grained scope-based access control
- Industry standard with extensive ecosystem support
- Supports diverse client types (web, mobile, server, IoT)
- Separates authentication from authorization concerns
- Refresh tokens enable long-lived sessions without long-lived access tokens
Weaknesses
- Complex specification with many grant types and extensions
- Easy to implement incorrectly (security-sensitive protocol)
- Does not define user identity (need OIDC for authentication)
- Authorization server can become a single point of failure
- Token management adds operational complexity
- Consent fatigue -- users may blindly accept permission requests
Likely Follow-Up Questions
- Walk through the authorization code flow with PKCE step by step.
- How would you design an OAuth 2.0 scope system for a multi-tenant SaaS platform?
- What's the difference between OAuth 2.0 and OpenID Connect?
- How do you handle token revocation in a system using JWT access tokens?
- What security risks exist if the redirect URI validation is not strict enough?
- How would you implement OAuth 2.0 for a mobile app vs a single-page application?
Related Auth Methods
Source: editorial — Comprehensive OAuth 2.0 coverage including grant types, security analysis, and scaling considerations for systems design interviews.