OAuth 2.0

What is OAuth 2.0?

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to a web service on behalf of a resource owner without exposing the owner's credentials. Defined in RFC 6749, OAuth 2.0 works by issuing access tokens to client applications after the resource owner grants consent, allowing the client to access protected resources within defined scopes and time limits.

OAuth 2.0 replaced the original OAuth 1.0 protocol by simplifying the flow and removing the requirement for cryptographic signatures on every request. Instead, it relies on TLS for transport security and introduces multiple grant types tailored to different application architectures -- server-side web apps, single-page apps, mobile apps, and machine-to-machine services.

The protocol has become the de facto standard for API authorization across the internet. Nearly every major platform -- Google, Facebook, GitHub, Microsoft, Twitter -- uses OAuth 2.0 to allow third-party integrations. It is also the foundation for OpenID Connect, which extends OAuth 2.0 with an identity layer for authentication. For a comprehensive treatment, see OAuth 2 in Action.

How OAuth 2.0 Works

The most common flow is the Authorization Code Grant, recommended for server-side applications:

• Client redirects to authorization server -- The application redirects the user's browser to the authorization server's /authorize endpoint with the requested scopes, a redirect URI, and a state parameter for CSRF protection.
• User authenticates and consents -- The authorization server authenticates the user and presents a consent screen showing what access the client is requesting.
• Authorization code returned -- Upon consent, the server redirects back to the client's redirect URI with a short-lived authorization code.
• Client exchanges code for tokens -- The client makes a back-channel POST to the /token endpoint with the authorization code, client credentials, and redirect URI.
• Tokens issued -- The authorization server returns an access token (and optionally a refresh token). The access token is typically a JWT or an opaque string.
• Client accesses protected resources -- The client includes the access token in API requests, usually as a Bearer token in the Authorization header.

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

For public clients (SPAs and mobile apps), the Authorization Code flow is extended with PKCE (Proof Key for Code Exchange, RFC 7636) to prevent authorization code interception.

OAuth 2.0 in Practice

OAuth 2.0 is implemented by virtually every major identity platform. Authorization servers like Okta, Auth0, Microsoft Entra ID, and Keycloak provide out-of-the-box OAuth 2.0 endpoints. Cloud providers such as AWS, Google Cloud, and Azure use OAuth 2.0 for API access management.

A common pattern is to combine OAuth 2.0 with OpenID Connect for both authentication and authorization in a single flow. The client requests an openid scope alongside resource-specific scopes, receiving both an ID token (for identity) and an access token (for API access).

In microservices architectures, OAuth 2.0 access tokens serve as the primary mechanism for service-to-service authorization, often using the Client Credentials grant. Token introspection (RFC 7662) and JWT-based access tokens allow resource servers to validate tokens without calling back to the authorization server on every request.

Common Misconceptions

"OAuth 2.0 is an authentication protocol." OAuth 2.0 is an authorization framework. It delegates access but does not, by itself, verify who the user is. OpenID Connect adds the authentication layer on top of OAuth 2.0. Using raw OAuth 2.0 for authentication without OIDC can lead to security vulnerabilities. "Access tokens should be stored in localStorage." Storing tokens in browser localStorage exposes them to cross-site scripting (XSS) attacks. Best practices recommend using httpOnly cookies or a backend-for-frontend (BFF) pattern to keep tokens out of JavaScript's reach. "The Implicit Grant is fine for SPAs." The Implicit Grant was originally designed for browser-based apps but is now considered insecure because it exposes tokens in the URL fragment. The current best practice (RFC 9126, OAuth 2.0 Security BCP) is to use the Authorization Code flow with PKCE for all public clients.

Key Standards & RFCs

• RFC 6749 -- The core OAuth 2.0 Authorization Framework specification.
• RFC 6750 -- Defines how to use Bearer tokens in HTTP requests.
• RFC 7636 (PKCE) -- Proof Key for Code Exchange, securing the Authorization Code flow for public clients.
• RFC 7662 -- Token Introspection, allowing resource servers to query token validity.
• RFC 9126 -- OAuth 2.0 Pushed Authorization Requests (PAR) for enhanced security.
• OAuth 2.0 Security Best Current Practice (BCP) -- Comprehensive security recommendations for OAuth 2.0 deployments.

Frequently Asked Questions

What is OAuth 2.0?

OAuth 2.0 is an authorization framework that allows applications to access user resources on another service without handling the user's password, using access tokens instead.

How does OAuth 2.0 work?

A user authorizes a client application at an authorization server, which issues an access token. The client uses this token to call APIs on the user's behalf, within the permissions (scopes) the user approved.

What is OAuth 2.0 used for?

OAuth 2.0 is used for delegated API authorization -- allowing third-party apps to access user data (e.g., "Sign in with Google"), securing microservice-to-microservice communication, and managing API access controls.

What are the benefits of OAuth 2.0?

Users never share their passwords with third-party apps, access can be scoped and time-limited, tokens can be revoked without changing passwords, and the framework supports diverse application types.

OAuth 2.0 vs OAuth 1.0?

OAuth 2.0 is simpler, drops per-request cryptographic signatures in favor of TLS, introduces multiple grant types for different use cases, and supports refresh tokens. OAuth 1.0 is largely deprecated.