OAuth2
Category: Security
What is OAuth 2.0?
OAuth 2.0 is an open standard for authorization, which allows applications to receive limited access to user accounts in web applications. It provides "secure delegated access" to server resources on behalf of the resource owner.
OAuth 2.0 is a fundamental protocol for modern web security and is used by almost all major technology companies.
Basic concepts in OAuth 2.0:
- Resource Owner - The user who owns the protected resources and can give access to them
- Client - The application that wants to access the protected resources on behalf of the resource owner
- Authorization Server - The server that issues access tokens to the client after successful authorization
- Resource Server - The server that hosts the protected resources and accepts access tokens for access to them
- Access Token - Token that gives access to specific resources for a certain period of time
- Scope - A set of permissions that the client wants from the resource owner
OAuth 2.0 Authorization Code Flow:
- 1
Authorization Request
The client redirects the user to the authorization server
- 2
User Authentication
The user authenticates and gives consent for access
- 3
Authorization Grant
Authorization server redirects back to the client with authorization code
- 4
Token Request
The client sends authorization code for access token
- 5
Access Token Response
Authorization server returns access token
- 5
API Access
The client uses access token for access to protected resources
Types of Grant Flows in OAuth 2.0:
Authorization Code
Characteristics:
- Most secure flow for web applications
- Uses server-to-server communication
- Supports client secret
- Ideal for web applications with backend
Used for:
- Traditional web applications
- Single Page Applications with backend
- Mobile applications with backend
Authorization Code with PKCE
Characteristics:
- Improved security for public clients
- Uses code verifier and code challenge
- Prevents authorization code interception
Used for:
- Single Page Applications
- Mobile applications
- Desktop applications
Implicit (Deprecated)
Characteristics:
- Deprecated - not recommended
- Direct return of access token
- Less secure
Replaced with:
- Authorization Code with PKCE
Client Credentials
Characteristics:
- Machine-to-machine communication
- No user involvement
- Uses client ID and secret
Used for:
- API-to-API communication
- Background services
- Automated processes
Resource Owner Password Credentials
Characteristics:
- Direct submission of username/password
- High trust level between client and server
- Not recommended for public clients
Used for:
- First-party applications
- Highly trusted environments
Device Authorization
Characteristics:
- For devices with limited input capability
- Uses device code and user code
- The user authorizes on another device
Used for:
- Smart TV applications
- Gaming consoles
- IoT devices
Tokens in OAuth 2.0:
Access Token
Characteristics:
- Short-lived - usually 1 hour
- Gives access to protected resources
- Sent in Authorization header
- Can be JWT or opaque token
Example:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Refresh Token
Characteristics:
- Long-lived - days, weeks or months
- Used for obtaining a new access token
- Stored securely on the server
- Can be revoked (revoked)
Refresh request:
POST /token Content-Type: application/x-www-form-urlencoded grant_type=refresh_token& refresh_token=REFRESH_TOKEN& client_id=CLIENT_ID& client_secret=CLIENT_SECRETID Token (OpenID Connect)
Characteristics:
- JWT token containing user information
- Part of OpenID Connect extension
- Contains claims for the user
- Used for authentication
Security best practices:
- Use HTTPS - Always use HTTPS for all OAuth communications
- Validate redirect_uri - Strictly validate and restrict allowed redirect URIs
- Use State parameter - Always use state parameter to prevent CSRF attacks
- Use PKCE - For all public clients (SPA, mobile apps) use PKCE
- Restrict token lifetimes - Use short-lived access tokens and secure refresh tokens
- Regulate scopes - Principle of least privilege - give only the necessary permissions
Real examples of OAuth 2.0:
- “Sign in with Google/Facebook” - When a website allows you to sign in with your Google or Facebook account
- Access to Gmail API - Application that wants access to your emails in Gmail
- API access to cloud services - Applications that access AWS, Azure or Google Cloud APIs
- Payment systems - Stripe, PayPal and other payment systems use OAuth 2.0
- Business APIs - Salesforce, Slack, GitHub and other enterprise platforms
OAuth 2.0 against OpenID Connect:
OAuth 2.0
Characteristics:
- Authorization - gives access to resources
- Returns Access Token
- Question: “What can this application do?”
- Delegated access
OpenID Connect (OIDC)
Characteristics:
- Authentication - confirms identity
- Returns ID Token + Access Token
- Question: “Who is this user?”
- Extension of OAuth 2.0
Popular OAuth 2.0 libraries:
JavaScript/Node.js
- Passport.js - Authentication middleware
- oauth2-server - Complete OAuth 2.0 implementation
- simple-oauth2 - Light OAuth 2.0 client library
Python
- Authlib - OAuth 1/2 and OpenID Connect
- requests-oauthlib - OAuth support for Requests
- django-oauth-toolkit - OAuth 2.0 for Django
Java
- Spring Security OAuth - OAuth support for Spring
- Apache Oltu - OAuth implementation
- ScribeJava - Simple OAuth library
C#/.NET
- IdentityServer - OpenID Connect and OAuth 2.0 framework
- Microsoft.Identity.Web - Official Microsoft library
- OAuth.NET - OAuth 2.0 implementation