OAuth 2.0

Definition

OAuth 2.0 (Open Authorization 2.0) is an industry-standard protocol for authorization that enables applications to obtain limited access to user accounts on an HTTP service. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that user account.

Why It Matters

OAuth 2.0 solves the problem of sharing credentials between applications. Instead of giving your password to a third-party app, OAuth allows you to grant limited access without revealing your credentials.

Key benefits:

Security - No password sharing
Granular permissions - Apps request only needed scopes
Revocable access - Users can revoke access anytime
Standardization - Widely adopted across the industry

How It Works

sequenceDiagram
    autonumber
    participant User as End User
    participant Client as Client Application
    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 Prompt
    User->>AuthServer: 4. Approve Access
    AuthServer->>Client: 5. Authorization Code
    Client->>AuthServer: 6. Exchange Code for Token
    AuthServer->>Client: 7. Access Token + Refresh Token
    Client->>ResourceServer: 8. API Request with Access Token
    ResourceServer->>Client: 9. Protected Resource

Step-by-Step Flow

User initiates login - Clicks “Login with Google/GitHub/etc.”
Authorization request - Client redirects to authorization server
User authentication - User logs in and sees permission request
User consent - User approves requested scopes
Authorization code - Server redirects back with temporary code
Token exchange - Client exchanges code for access token (backend)
Access granted - Client receives access token and refresh token
API access - Client uses access token to call protected APIs
Data returned - Resource server validates token and returns data

Common Use Cases

Third-Party Integrations

Allow users to connect your app to their existing accounts:

GET /oauth/authorize?
  response_type=code&
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/callback&
  scope=read:user,write:repo&
  state=random_state_string

Single Sign-On (SSO)

Enable users to log in once and access multiple applications:

Enterprise applications
Multi-product suites
Partner integrations

Mobile & SPA Applications

Use PKCE (Proof Key for Code Exchange) for secure authentication without client secrets.

Best Practices

Always use HTTPS - Never transmit tokens over unencrypted connections
Validate redirect URIs - Prevent authorization code interception
Use PKCE - Required for mobile/SPA apps, recommended for all
Short-lived access tokens - Typically 15-60 minutes
Secure token storage - Never store tokens in localStorage
Implement token refresh - Use refresh tokens to get new access tokens
Validate state parameter - Prevent CSRF attacks

Common Pitfalls

Issue	Impact	Solution
Storing tokens in localStorage	XSS vulnerability	Use httpOnly cookies or secure storage
Not validating state	CSRF attacks	Always validate state parameter matches
Overly broad scopes	Excessive permissions	Request minimum required scopes
Missing PKCE	Authorization code interception	Implement PKCE for all flows
Long-lived access tokens	Increased attack window	Use short expiration + refresh tokens

JWT - Token format often used with OAuth
PKCE - Extension for public clients
OpenID Connect - Identity layer built on OAuth 2.0
Refresh Tokens - Long-lived tokens to obtain new access tokens