OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on third-party services without exposing user credentials. OAuth 2.0 delegates authentication to authorization servers and issues time-limited access tokens, enabling secure API access delegation across web, mobile, and desktop applications.
Unlike direct credential sharing, OAuth 2.0 allows users to grant specific permissions (scopes) to applications without sharing passwords. A photo editing app can access Google Photos without seeing your Google password. An analytics tool can read GitHub repository data without full account access. This scoped delegation model powers modern SSO integrations and third-party API ecosystems.
OAuth 2.0 works alongside authentication protocols like OpenID Connect (OIDC). While OAuth 2.0 handles authorization (what you can do), OIDC handles authentication (who you are). Most modern implementations combine both: OIDC for login, OAuth 2.0 for API access.
How OAuth 2.0 Works
OAuth 2.0 defines four roles: resource owner (user), client (application requesting access), authorization server (issues tokens), and resource server (API with protected data). The framework specifies grant types (flows) for different scenarios, each optimized for specific application types and security requirements.
The authorization flow begins when a client application requests access to protected resources. The authorization server authenticates the resource owner, obtains consent, and issues an access token. The client uses this token to access protected resources on the resource server. Tokens have limited lifetimes and scopes, reducing exposure from credential compromise.
Access tokens represent authorization decisions and contain scopes (permissions), expiration times, and metadata. Refresh tokens enable long-lived access without repeated user interaction. The separation between access and refresh tokens balances security (short-lived access tokens) with user experience (seamless token renewal).
OAuth 2.0 Grant Types
Authorization Code Grant
Server-side applications exchange authorization codes for tokens. Most secure grant for web applications with server-side code execution. Authorization code flow supports PKCE (Proof Key for Code Exchange) for public clients like mobile apps and SPAs.
Client Credentials Grant
Machine-to-machine communication without user context. Services authenticate with their own credentials and receive tokens for API access. Used for background jobs, service-to-service communication, and automated workflows.
Implicit Grant (Deprecated)
Originally designed for browser-based applications. Deprecated due to security concerns (tokens exposed in URL fragments). Modern applications should use Authorization Code with PKCE instead.
Resource Owner Password Credentials Grant
User provides username/password directly to client. Only use for legacy migration or trusted first-party applications. Generally discouraged due to credential exposure risk.
Refresh Token Grant
Exchange refresh token for new access token without user interaction. Enables long-lived sessions without storing user credentials. Refresh tokens should be securely stored and rotated regularly.
When to Use OAuth 2.0
Use OAuth 2.0 when you need:
- Third-party application access to user data without credential sharing
- Single sign-on (SSO) across multiple applications
- Scoped API access with granular permissions
- Mobile and SPA authentication with PKCE
- Service-to-service authentication (Client Credentials)
- Long-lived sessions with refresh tokens
- Federation with identity providers (Google, GitHub, Microsoft)
Do not use OAuth 2.0 when you need:
- Simple internal API authentication (consider API keys)
- User authentication alone without authorization (use OIDC)
- One-time access without persistent sessions (stateless tokens like JWT may suffice)
- Legacy systems requiring password authentication (consider migration strategy)
Signals You Need OAuth 2.0
- Third-party applications requesting access to your users’ data
- Users authenticating via social logins (Google, GitHub, LinkedIn)
- Mobile applications needing secure API access
- Microservices requiring service-to-service authentication
- Need to revoke application access without changing user passwords
- Compliance requirements for credential isolation
Metrics and Measurement
Security Metrics:
- Token validation success rate: Percentage of tokens validating successfully (target: >99%)
- Token revocation latency: Time for revocation to propagate (target: <30 seconds)
- Authorization code reuse attempts: Should be zero (indicates PKCE implementation)
- Refresh token rotation rate: Percentage of refresh tokens rotated after use
Performance Metrics:
- Authorization endpoint latency: Time to complete OAuth flow (target: <500ms)
- Token endpoint latency: Time to issue token (target: <100ms)
- Token introspection latency: Time to validate token at authorization server (target: <50ms with local validation)
Operational Metrics:
- Active token count: Number of valid access tokens across applications
- Token expiration rate: Percentage of requests failing due to expired tokens
- Consent rate: Percentage of users granting requested scopes
- Scope rejection rate: Frequency of users denying specific permissions
According to OAuth 2.0 security best practices (RFC 6819), access tokens should have short lifetimes (minutes to hours) and refresh tokens should implement rotation to detect token theft.
OAuth 2.0 Architecture
Authorization Server
Issues tokens after authenticating resource owner and obtaining consent. Implements token endpoints for exchange, introspection, and revocation. Popular implementations include Auth0, Okta, Keycloak, and cloud provider services (AWS Cognito, Azure AD).
Resource Server
API hosting protected resources. Validates access tokens before granting access. Performs scope validation and enforces permissions. May introspect tokens with authorization server or validate locally with JWT.
Client Application
Requests access to protected resources. Must be registered with authorization server. Implements OAuth flows appropriate for application type. Secures client credentials and tokens.
Scopes and Permissions
Scopes define access boundaries (read:profile, write:data, admin). Resource servers validate scopes match required permissions. Granular scopes enable least-privilege access.
Real-World Use Cases
Third-Party API Access
- Social login integration (Sign in with Google, GitHub)
- Third-party apps accessing user data (CRM reading email contacts)
- API marketplaces with scoped access
- Developer platforms with API authorization
Enterprise SSO
- Single sign-on across organizational applications
- Federation with external identity providers
- Centralized access control and auditing
- Delegated administration across departments
Mobile Applications
- Secure API authentication with PKCE
- Biometric authentication integrated with token refresh
- Offline access patterns with long-lived refresh tokens
- Session management across device changes
Microservices Architecture
- Service-to-service authentication with Client Credentials
- API gateway token validation and propagation
- Delegated authorization claims between services
- Zero-trust network architecture with token-based access
IoT and Device Authorization
- Device flow for input-constrained devices
- Token-based API access for IoT devices
- Scoped permissions for device capabilities
- Long-lived authorization with refresh tokens
Common Mistakes and Fixes
Mistake: Using implicit grant for browser applications Fix: Use Authorization Code flow with PKCE. Implicit grant exposes tokens in browser history andreferrer headers. PKCE prevents authorization code interception attacks while maintaining SPA compatibility.
Mistake: Storing tokens in localStorage vulnerable to XSS Fix: Store tokens in HttpOnly cookies or secure browser storage. For SPAs, use the Browser Session Management pattern with rotating refresh tokens. Consider the security implications of each storage mechanism for your threat model.
Mistake: Long-lived access tokens without refresh mechanism Fix: Implement short-lived access tokens (5-60 minutes) with refresh tokens. This limits exposure from token theft while maintaining user experience through automatic token renewal.
Mistake: Not validating scopes on resource server Fix: Resource servers must validate token scopes match required permissions for each endpoint. Don’t assume client application enforces least privilege. Validate both token signature and scope claims.
Mistake: Using Resource Owner Password Credentials grant Fix: Migrate to Authorization Code or Client Credentials grants. Password credentials grant exposes user passwords to third-party applications, defeating OAuth 2.0’s primary security benefit.
Mistake: Not implementing token revocation Fix: Implement revocation endpoint for access and refresh tokens. Users should be able to revoke application access immediately. Token revocation should propagate quickly across all resource servers.
Frequently Asked Questions
What is the difference between OAuth 2.0 and OpenID Connect (OIDC)? OAuth 2.0 handles authorization (what you can access). OIDC adds an authentication layer (who you are) by introducing ID tokens with user identity claims. OIDC uses OAuth 2.0 flows but returns ID tokens alongside access tokens. Use OIDC when you need user authentication, OAuth 2.0 when you need API access delegation.
How do refresh tokens work? Refresh tokens are long-lived credentials that obtain new access tokens. When an access token expires, the client sends the refresh token to the token endpoint and receives a new access token. Refresh tokens should be securely stored, rotated after use, and revocable. Not all grant types support refresh tokens.
What is PKCE and when should I use it? PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks in public clients. Use PKCE for all browser-based applications (SPAs), mobile apps, and any client that cannot securely store a client secret. PKCE binds the authorization code to a code verifier known only to the client.
Should I use JWT or opaque tokens for access tokens? JWTs enable local validation without authorization server round-trips, improving performance and reducing server load. Opaque tokens require introspection but are simpler to revoke. Use JWTs when resource servers need fast validation, opaque tokens when revocation latency is critical. Many implementations use JWT access tokens with opaque refresh tokens.
How do I secure client credentials in public clients? Public clients (SPAs, mobile apps) cannot securely store client secrets. Use PKCE to protect authorization codes. Consider dynamic client registration or assertion-based client authentication. For SPAs, avoid client secrets entirely—use token mediation through a backend component if additional security is required.
What scopes should I define? Define scopes based on access boundaries relevant to your domain: resource types (read:profile, write:documents), functional capabilities (admin, analytics), or API groups (calendar, email). Avoid overly granular scopes (causes permission fatigue) or overly broad scopes (violates least privilege). Test scope UX with real authorization consent screens.
How do I implement token revocation? Implement revocation endpoint per RFC 7009. When users revoke application access, invalidate the refresh token and all associated access tokens. For JWT access tokens, maintain a token blacklist or use short expiration times with revocable refresh tokens. Consider token introspection caching for frequently accessed tokens.
How This Applies in Practice
OAuth 2.0 is the foundation for modern API authorization and third-party integration. Most developers encounter OAuth 2.0 through social login buttons, API integrations, or enterprise SSO implementations. Understanding grant types, security considerations, and token management enables secure application architecture.
Implementation Strategy:
- Choose appropriate grant type for application architecture
- Register client applications with authorization server
- Implement OAuth flows with PKCE for public clients
- Validate tokens and scopes on resource servers
- Handle token refresh and expiration gracefully
- Implement secure token storage for client type
Security Best Practices:
- Use short-lived access tokens with refresh token rotation
- Validate redirect URIs strictly to prevent open redirect attacks
- Implement PKCE for all public clients
- Store tokens securely based on client type
- Validate scopes on every resource server request
- Implement token revocation and consent management
Architecture Decisions:
- Use Authorization Code with PKCE for SPAs and mobile apps
- Use Client Credentials for service-to-service communication
- Consider JWT access tokens for distributed validation
- Centralize token introspection for revocation-sensitive applications
- Implement authorization server or use managed service (Auth0, Okta)
- Design scopes for least privilege and user understanding
OAuth 2.0 on Azion
Azion Functions enable OAuth 2.0 integration at the web platform layer:
- Token validation in Functions before forwarding requests to origin servers
- Authorization server integration with edge token introspection
- Scope extraction for fine-grained authorization decisions
- Rate limiting and abuse prevention for token endpoints
- Real-Time Metrics for authentication events and token usage
The distributed nature of Azion’s global network enables token validation closer to users, reducing latency for authorization checks while maintaining security. Functions can cache token introspection results for improved performance without compromising token revocation capabilities.
Learn more about Functions and API Security.