System Designer
Back to Technology

OAuth 2.0

Master modern API authorization with the industry-standard framework for secure access delegation

40 min read•
Not Started

What is OAuth 2.0?

OAuth 2.0 is an industry-standard authorization framework that enables applications to obtain limited access to user accounts on HTTP services. It works by delegating user authentication to the service that hosts the user account and authorizing third-party applications to access that user account without exposing the user's credentials.

Published as RFC 6749 in 2012, OAuth 2.0 replaced OAuth 1.0 and has become the foundation for modern API security. It's used by major platforms like Google, Facebook, Twitter, and GitHub to allow third-party applications secure access to user data. OAuth 2.0 focuses on simplicity for client developers while providing specific authorization flows for different application types.

OAuth 2.0 Performance Calculator

25000
Tokens/Hour
100
Security Score
300ms
Auth Time
33
Requests/Second

Server Memory: 2250MB

DB Connections: 10

Token Storage: 25MB

OAuth 2.0 Roles and Components

Resource Owner

The user who owns the data and can grant access to it.

• End user or system
• Owns protected resources
• Grants authorization
• Controls access scope
• Can revoke permissions

Client

The application requesting access to protected resources.

• Web applications
• Mobile apps
• Single-page apps
• Server-to-server
• Public or confidential

Authorization Server

Issues access tokens after authenticating the resource owner.

• Authenticates users
• Issues access tokens
• Manages authorization
• Validates scopes
• Handles token refresh

Resource Server

The API server hosting the protected resources.

• Hosts protected resources
• Validates access tokens
• Enforces scopes
• Serves API requests
• Logs access attempts

OAuth 2.0 Authorization Flows

Authorization Code Flow

Most secure flow for web applications. Uses server-side code exchange.

1. Client redirects user to authorization server
2. User authenticates and grants permission
3. Authorization server redirects with authorization code
4. Client exchanges code for access token (server-side)
5. Client uses access token to access protected resources
✅ Best for: Web applications, mobile apps with PKCE

Implicit Flow

Simplified flow that returns tokens directly from authorization endpoint.

1. Client redirects user to authorization server
2. User authenticates and grants permission
3. Authorization server redirects with access token in URL fragment
4. Client extracts token from URL and uses it
⚠️ Note: Being phased out in favor of Authorization Code + PKCE

Client Credentials Flow

Used for server-to-server communication where no user is involved.

1. Client authenticates with client credentials
2. Authorization server validates credentials
3. Authorization server issues access token
4. Client uses access token to access protected resources
✅ Best for: API-to-API communication, background services

OAuth 2.0 Security Considerations

Common Vulnerabilities

• Authorization code interception
• Cross-site request forgery
• Token replay attacks
• Insufficient redirect URI validation
• Client authentication bypass
• Scope elevation attacks

Security Best Practices

• Use PKCE for public clients
• Implement proper redirect URI validation
• Use state parameter for CSRF protection
• Implement token rotation
• Use short-lived access tokens
• Validate all input parameters

PKCE Extension

• Proof Key for Code Exchange
• Prevents code interception
• Required for mobile apps
• Recommended for SPAs
• Uses cryptographic challenge

Token Management

• Short access token lifetime
• Secure refresh token storage
• Token rotation on refresh
• Proper token revocation
• Audience validation

Real-World OAuth 2.0 Implementations

Google APIs

Comprehensive OAuth 2.0 implementation for accessing Google services.

  • • Gmail, Calendar, Drive APIs
  • • Fine-grained scopes
  • • Incremental authorization
  • • Offline access support

GitHub OAuth Apps

Developer platform integration using OAuth 2.0 for repository access.

  • • Repository permissions
  • • Organization access
  • • CI/CD integrations
  • • Third-party app ecosystem

Spotify Web API

Music platform API access with user playlist and playback control.

  • • Playlist management
  • • Playback control
  • • User profile access
  • • Music discovery features

Salesforce Connected Apps

Enterprise CRM platform with OAuth 2.0 for secure API integrations.

  • • CRM data access
  • • Custom app integrations
  • • Enterprise SSO
  • • Mobile app authentication

OAuth 2.0 Implementation Example

Authorization Request

Redirecting user to authorization server with proper parameters.

Authorization Request
GET /authorize?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=https://yourapp.com/callback&
  scope=read:user read:repo&
  state=random_state_string&
  code_challenge=base64url_encoded_challenge&
  code_challenge_method=S256

Token Exchange

Exchanging authorization code for access token on the server side.

Token Exchange Request
POST /token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=received_authorization_code&
redirect_uri=https://yourapp.com/callback&
client_id=your_client_id&
client_secret=your_client_secret&
code_verifier=original_code_verifier

Using Access Token

Making authenticated API requests with the access token.

Using Access Token
GET /api/user
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6...
Accept: application/json

# Response
{
  "id": "12345",
  "username": "john_doe",
  "email": "john@example.com"
}

OAuth 2.0 Best Practices

✅ Do

  • • Always use HTTPS for all OAuth endpoints
  • • Implement PKCE for public clients
  • • Use state parameter to prevent CSRF
  • • Validate all redirect URIs strictly
  • • Implement proper scope validation
  • • Use short-lived access tokens
  • • Implement token refresh properly

❌ Don't

  • • Store client secrets in public clients
  • • Use implicit flow for new applications
  • • Skip redirect URI validation
  • • Ignore the state parameter
  • • Use overly broad scopes
  • • Store tokens in insecure locations
  • • Forget to implement token revocation

📝 OAuth 2.0 Quiz

1 of 6Current: 0/6

What is OAuth 2.0 primarily designed for?