Category: Identity and Access Management

OAuth

Also known as: OAuth, Open Authorization, OAuth 2.0

Simply put

OAuth (Open Authorization) is an open standard that allows a user to grant one application permission to interact with another application on their behalf, without sharing their password or private credentials. For example, it enables a third-party app to access a user's data from a service like Google without the user ever revealing their login details to that third-party app. Most modern implementations use OAuth 2.0, which is the current industry-standard version of the protocol.

Formal definition

OAuth is an open standard authorization framework and access delegation protocol that enables a client application to obtain scoped, delegated access to protected resources hosted by a resource server, acting on behalf of a resource owner, without requiring the resource owner to share their credentials with the client. OAuth 2.0, the dominant version in production use, defines multiple authorization grant flows (including Authorization Code, Client Credentials, Device Authorization, and Implicit, though Implicit is deprecated in current best practices) to accommodate varying client types such as web server applications, single-page applications, and native clients. The protocol issues access tokens, and optionally refresh tokens, to clients following user consent, with the scope of access constrained by the authorization server. OAuth 2.0 is focused strictly on authorization and access delegation; it does not itself define an authentication mechanism, though it is commonly extended by OpenID Connect (OIDC) to provide identity verification on top of the authorization layer.

Why it matters

OAuth addresses one of the most fundamental risks in modern application ecosystems: the need for applications to access user data or act on a user's behalf across service boundaries without requiring the user to hand over their password. Before delegation protocols like OAuth, users routinely shared credentials directly with third-party applications, creating broad exposure if any one of those applications was compromised. OAuth replaces that pattern with scoped, time-limited access tokens, so a third party receives only the minimum necessary permissions rather than full account access.

For application security practitioners, OAuth is a critical control point because its implementation complexity introduces meaningful attack surface. Misconfigured redirect URIs, improper state parameter validation, and confused authorization flows have been implicated in real-world token hijacking and account takeover incidents. The deprecation of the Implicit grant flow in current best practices reflects discovered weaknesses in how tokens were exposed in browser environments, illustrating that the protocol continues to evolve in response to identified threats.

OAuth also sits at the boundary between authorization and authentication, a distinction that matters practically. OAuth 2.0 itself does not verify identity; it delegates access. When developers treat an OAuth access token as proof of who a user is, rather than what the user has authorized, they typically introduce authentication logic errors. OpenID Connect was layered on top of OAuth 2.0 specifically to address this gap, and understanding where one ends and the other begins is essential for building secure integrations.

Who it's relevant to

Application Developers

Developers integrating third-party services or building platforms that expose APIs need to understand which OAuth 2.0 grant flow is appropriate for their client type, how to validate redirect URIs, how to handle state parameters to prevent cross-site request forgery, and how to store and transmit tokens securely. Incorrectly implementing any of these elements can introduce token hijacking or privilege escalation vulnerabilities.

Security Engineers and AppSec Reviewers

Security reviewers assessing OAuth implementations look for misconfigurations such as overly permissive redirect URI validation, use of deprecated flows like Implicit, missing or weak state parameter handling, and excessive token scopes. Code-level review can surface some of these issues, though validating runtime token behavior and authorization server configuration typically requires dynamic testing and environment inspection.

Identity and Access Management (IAM) Teams

IAM practitioners are responsible for configuring authorization servers, defining token lifetimes, enforcing scope policies, and managing client registrations. Decisions made at the authorization server level, such as whether refresh tokens are issued and how long access tokens remain valid, have direct security implications for every application relying on that OAuth deployment.

Platform and API Architects

Architects designing systems where multiple services must share access to user resources need to model the trust relationships between clients, resource servers, and authorization servers. OAuth's delegation model supports least-privilege access patterns across service boundaries, but realizing those benefits depends on scopes being defined narrowly and enforced consistently at the resource server.

Security Operations and Incident Responders

When access tokens are compromised or misused, security operations teams need visibility into token issuance, scope grants, and usage patterns to detect anomalies and revoke access without disrupting legitimate users. OAuth's token-based model allows targeted revocation of delegated access without requiring credential rotation, which can limit the blast radius of a compromised integration.

Inside OAuth

Resource Owner

The entity (typically an end user) who owns the protected resources and can grant third-party applications limited access to those resources without sharing credentials.

Client

The application requesting access to protected resources on behalf of the resource owner. Clients may be confidential (capable of storing secrets securely) or public (unable to store secrets securely, such as mobile or single-page applications).

Authorization Server

The server responsible for authenticating the resource owner, obtaining authorization consent, and issuing access tokens and optionally refresh tokens to the client.

Resource Server

The server hosting the protected resources. It accepts and validates access tokens to determine whether to fulfill a client request.

Access Token

A credential issued by the authorization server that represents the authorization granted to the client. Access tokens typically have a limited lifetime and defined scope, and are presented to the resource server to access protected resources.

Refresh Token

An optional credential issued alongside an access token that allows the client to obtain a new access token without requiring the resource owner to re-authenticate. Refresh tokens are typically longer-lived and must be stored securely.

Authorization Grant

A credential representing the resource owner's authorization, used by the client to obtain an access token. OAuth 2.0 defines several grant types including Authorization Code, Client Credentials, and Device Authorization Grant.

Scopes

Mechanism used to limit the access granted to a client. Scopes define the specific permissions being requested and granted, allowing the resource owner to grant only the level of access needed.

Redirect URI

The URI to which the authorization server sends the resource owner's browser after authorization. Strict validation of redirect URIs is a critical security control to prevent authorization code or token interception.

State Parameter

An opaque value used by the client to maintain state between the authorization request and callback. It also serves as a CSRF protection mechanism by binding the request to the client session.

PKCE (Proof Key for Code Exchange)

An extension to the Authorization Code flow that uses a code verifier and code challenge to prevent authorization code interception attacks, particularly important for public clients such as mobile and single-page applications.

Common questions

Answers to the questions practitioners most commonly ask about OAuth.

Does OAuth authenticate users and tell my application who they are?

No. OAuth is an authorization protocol, not an authentication protocol. It is designed to grant third-party applications access to resources on behalf of a user, not to verify the user's identity to your application. Using OAuth tokens alone to determine who a user is typically leads to security vulnerabilities. OpenID Connect, which is built on top of OAuth 2.0, adds an identity layer and is the appropriate protocol to use when authentication is the goal.

Does using OAuth mean my application never needs to handle passwords?

Not necessarily. OAuth governs how your application obtains delegated access to resources at a third-party service. If your application also maintains its own user accounts, it may still manage credentials for those accounts. OAuth may reduce or eliminate password handling in specific delegation flows, but it does not automatically remove all credential management responsibilities from your application.

What is the difference between an access token and a refresh token in OAuth, and how should each be stored?

An access token is a short-lived credential used to make authorized requests to a resource server. A refresh token is a longer-lived credential used to obtain new access tokens without requiring the user to re-authorize. Because refresh tokens carry greater risk if compromised, they should be stored more securely than access tokens, typically in httpOnly cookies or secure server-side storage rather than browser-accessible locations such as localStorage.

What is the recommended OAuth 2.0 flow for a single-page application?

The Authorization Code flow with PKCE (Proof Key for Code Exchange) is the recommended approach for single-page applications. The implicit flow, which was previously common for browser-based clients, is now discouraged because it returns tokens directly in the URL fragment and lacks the protections that PKCE provides against authorization code interception attacks.

How should an application validate an OAuth access token it receives from a client?

The resource server should validate the token's signature (for signed token formats such as JWT), confirm that the token has not expired, verify that the audience and issuer claims match expected values, and check that the granted scopes are sufficient for the requested operation. Tokens should be validated on every request rather than cached without re-verification, and revocation status should be checked where the authorization server supports it.

What is the state parameter in OAuth and why is it important?

The state parameter is an opaque value that the client generates and includes in the authorization request. The authorization server returns this value unchanged in the redirect response. The client verifies that the returned state matches the value it originally sent. This mechanism is used to prevent cross-site request forgery attacks against the OAuth callback endpoint. Omitting or failing to validate the state parameter is a common implementation mistake that leaves the authorization flow vulnerable to CSRF.

Common misconceptions

OAuth is an authentication protocol.

OAuth 2.0 is an authorization framework, not an authentication protocol. It delegates access to resources without conveying verified identity to the client. Authentication is addressed by a separate layer such as OpenID Connect, which is built on top of OAuth 2.0 and adds an ID token and a standardized mechanism for identity assertion.

Possession of a valid access token proves the identity of the user behind a request.

An access token proves that authorization was granted for a specific scope, but does not by itself confirm the identity of the resource owner at the time of the request. Tokens can be stolen or replayed within their validity window, so additional controls such as token binding, short expiry, and audience validation are needed to reduce misuse.

The implicit grant flow is the recommended approach for browser-based or mobile applications because it avoids a server-side component.

The implicit grant flow is now discouraged by current OAuth 2.0 security best practices (OAuth 2.0 Security Best Current Practice, RFC 9700) due to risks including token exposure in the browser history and lack of client authentication. The Authorization Code flow with PKCE is the recommended approach for public clients, including single-page and mobile applications.

Best practices

Always use the Authorization Code flow with PKCE for public clients, including single-page applications and mobile applications, rather than the implicit flow.

Enforce strict redirect URI validation on the authorization server, requiring exact string matching rather than pattern or prefix matching, to prevent open redirect and token hijacking attacks.

Request only the minimum scopes necessary for the application's functionality, and prompt users with clear descriptions of what access is being requested at the consent screen.

Store access tokens and refresh tokens securely: avoid storing tokens in browser localStorage or sessionStorage where script injection could expose them, and prefer memory storage or secure HttpOnly cookies with appropriate controls for web clients.

Implement short access token lifetimes and rotate refresh tokens on each use, invalidating the previous token, to limit the window of exposure from token theft.

Validate the audience, issuer, expiry, and scope of incoming access tokens on the resource server for every request, rather than relying solely on token possession as proof of authorization.