OAuth 2.0

Definition

OAuth 2.0 (Open Authorization 2.0) is an industry-standard authorization framework that enables third-party applications to obtain limited access to user accounts on an HTTP service without exposing user credentials.

Unlike OAuth 1.0, OAuth 2.0 focuses exclusively on authorization (not authentication), delegating the authentication process to separate protocols like OpenID Connect.

Context

OAuth 2.0 was designed to solve the problem of credential sharing. Before OAuth, users had to share their passwords with third-party apps to grant access to their data—a serious security risk.

Key Concepts

  • Resource Owner: The user who owns the data
  • Client: The application requesting access
  • Resource Server: The API hosting protected resources
  • Authorization Server: Issues access tokens after authenticating the user

Example

A typical OAuth 2.0 flow (Authorization Code Grant):

  1. User clicks “Login with Google” in App A
  2. App A redirects to Google’s authorization server
  3. User logs in and consents to requested permissions
  4. Google redirects back to App A with an authorization code
  5. App A exchanges the code for an access token
  6. App A uses the token to access Google APIs on behalf of the user

Code

Authorization Request

GET /authorize?response_type=code
    &client_id=abc123
    &redirect_uri=https://app.example.com/callback
    &scope=read:profile
    &state=xyz789 HTTP/1.1
Host: auth.example.com

Token Exchange

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=AUTH_CODE_HERE
&redirect_uri=https://app.example.com/callback
&client_id=abc123
&client_secret=secret456

Using Access Token

GET /api/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer ACCESS_TOKEN_HERE

Diagram

sequenceDiagram
    participant User
    participant Client as Client App
    participant AuthServer as Authorization Server
    participant ResourceServer as Resource Server

    User->>Client: 1. Initiate login
    Client->>AuthServer: 2. Authorization request
    AuthServer->>User: 3. Login & consent
    User->>AuthServer: 4. Approve
    AuthServer->>Client: 5. Authorization code
    Client->>AuthServer: 6. Exchange code for token
    AuthServer->>Client: 7. Access token
    Client->>ResourceServer: 8. API request with token
    ResourceServer->>Client: 9. Protected resource

Best Practices

  1. Always use HTTPS - OAuth 2.0 requires TLS encryption
  2. Use PKCE (Proof Key for Code Exchange) for public clients
  3. Short-lived access tokens - Expire in 1 hour or less
  4. Refresh tokens for long sessions - Store securely
  5. Validate redirect URIs - Prevent authorization code interception
  6. Use state parameter - Prevent CSRF attacks
  7. Limit scopes - Request minimum necessary permissions
  8. Rotate client secrets - Regularly update credentials

Common Mistakes

  1. Using implicit flow - Deprecated, use Authorization Code + PKCE instead
  2. Storing tokens in localStorage - XSS vulnerability, use httpOnly cookies
  3. Not validating state parameter - CSRF risk
  4. Overly broad scopes - Principle of least privilege
  5. Exposing client secrets - Keep in backend only
  6. Not using refresh tokens - Poor UX with frequent re-auth

Analogy

OAuth 2.0 is like a valet key for your car:

  • You (resource owner) give a valet (client) a special key
  • The valet key (access token) can only drive the car, not open the trunk (limited scope)
  • The valet can’t make a copy of your master key (no password sharing)
  • The key expires after a few hours (token expiration)
  • You can revoke the key anytime (token revocation)

Security

Threats

  • Authorization code interception - Mitigate with PKCE
  • Token leakage - Use short-lived tokens + refresh rotation
  • CSRF attacks - Validate state parameter
  • Phishing - Educate users on legitimate auth screens
  • Replay attacks - Use nonces and token binding

Recommendations

  • Implement token rotation for refresh tokens
  • Use JWT for self-contained tokens with signature verification
  • Enable rate limiting on token endpoints
  • Monitor for anomalous access patterns
  • Implement token revocation lists

Category: Authentication & Security Difficulty: Intermediate Last Updated: January 6, 2025

Also available in: