Category: OAuth & OIDC

OAuth 2.0

Also known as: Open Authorization 2.0

Simply put

OAuth 2.0 is a widely used standard that lets an application access resources hosted by another service on a user's behalf without the user sharing their password with that application. For example, it allows one app to obtain limited, delegated access to data held in another web application. It is designed to grant access to resources, not to verify who a user is.

Formal definition

OAuth 2.0 is an industry-standard delegated authorization framework that enables a client application to obtain scoped access to protected resources, typically via access tokens issued by an authorization server, without exposing the resource owner's credentials to the client. It defines several authorization flows (grant types), such as the authorization code grant, for different client scenarios and API access patterns. OAuth 2.0 is an authorization framework and is not, on its own, an authentication protocol; determining a user's identity requires an additional layer such as OpenID Connect built on top of OAuth 2.0. Note that some vendor documentation informally describes OAuth 2.0 as handling both authentication and authorization, but in the framework itself the identity/authentication function is out of scope.

Why it matters

OAuth 2.0 underpins much of the delegated access that modern web and mobile ecosystems depend on. It allows a client application to obtain scoped access to resources hosted by another service without the user ever handing their password to that client. This delegation model reduces credential exposure and lets resource owners grant limited, revocable access rather than sharing full account credentials, which is central to how APIs are secured today.

A persistent source of risk is the widespread misconception that OAuth 2.0 is an authentication protocol. It is a delegated authorization framework, and on its own it does not verify who a user is. Some vendor documentation informally describes OAuth 2.0 as handling both authentication and authorization, which can lead architects to build identity verification on primitives that were never designed for that purpose. When identity assertions are needed, OpenID Connect, which is built on top of OAuth 2.0, provides the authentication layer; treating a raw OAuth 2.0 access token as proof of user identity is a common and consequential design error.

Because OAuth 2.0 defines several distinct grant types for different client scenarios, choosing the appropriate flow, scoping access tokens narrowly, and validating tokens correctly all materially affect the security posture of an API deployment. The framework's flexibility is a strength for developers but also means that security depends heavily on how each flow and profile is configured.

Who it's relevant to

Security Architects

Architects designing API access patterns rely on OAuth 2.0 to enable delegated, scoped access without spreading credentials across clients. They must select appropriate grant types for each client scenario and, critically, avoid using OAuth 2.0 alone to authenticate users, layering OpenID Connect on top where identity verification is required.

IAM Engineers

Engineers implementing authorization servers and clients work directly with OAuth 2.0 flows such as the authorization code grant. They configure scopes, token issuance, and validation, and must ensure access tokens are treated as authorization grants rather than proof of identity.

Application Developers

Developers integrating with third-party APIs use OAuth 2.0 to obtain delegated access to resources hosted by other services on a user's behalf. Understanding the correct flow for their client type and the limits of what an access token asserts is essential to secure integration.

Compliance and Audit Leads

Those reviewing access controls need to understand that OAuth 2.0 governs delegated resource access, not identity verification. Distinguishing what a token authorizes from who a principal is helps them assess whether authentication and authorization concerns are correctly separated in a given deployment.

Inside OAuth 2.0

Resource Owner

The entity, typically an end user, that owns the protected resource and can grant access to it. The resource owner authorizes a client to act on their behalf without sharing credentials directly.

Client

The application requesting access to protected resources on behalf of the resource owner. OAuth 2.0 distinguishes confidential clients (able to keep credentials secret, such as server-side apps) from public clients (unable to, such as single-page or native apps), which affects which flows and protections apply.

Authorization Server

The server that authenticates the resource owner (out of band from OAuth itself), obtains authorization, and issues access tokens to the client. In most deployments it also exposes token and authorization endpoints.

Resource Server

The server hosting the protected resources that accepts and validates access tokens before serving requests. Token validation approach depends on whether tokens are opaque (requiring introspection) or self-contained.

Access Token

A credential used by the client to access protected resources. Access tokens represent a delegated authorization grant, not proof of user authentication. They may be opaque or self-contained (for example a JWT), and typically have a short lifetime.

Refresh Token

A credential used to obtain new access tokens without re-involving the resource owner, typically when the access token expires. Refresh tokens are usually longer-lived and, depending on configuration, may be rotated or bound to a specific client.

Authorization Grant

The mechanism representing the resource owner's authorization. OAuth 2.0 defines several grant types, including authorization code, client credentials, and others; the appropriate grant depends on the client type and deployment context.

Scopes

Parameters that express the extent of access the client requests. Scopes bound what an access token permits at the resource server, supporting least-privilege delegation.

Common questions

Answers to the questions practitioners most commonly ask about OAuth 2.0.

Can OAuth 2.0 be used to authenticate users?

Not on its own. OAuth 2.0 is a delegated authorization framework: it lets a client obtain limited access to resources on behalf of a resource owner. It does not define how to verify a user's identity or convey authentication events in a standardized way. Using access tokens as proof of authentication is a well-known anti-pattern. For authentication you should use OpenID Connect, which is the authentication layer built on top of OAuth 2.0 and adds the ID token and related mechanisms.

Is an OAuth 2.0 access token the same thing as an OpenID Connect ID token?

No. In OAuth 2.0 an access token is a credential the client presents to a resource server to access protected resources, and its format and audience are defined by the authorization server and resource server. An ID token is an OpenID Connect construct that carries claims about an authentication event and the authenticated user, intended for the client rather than a resource server. They serve different purposes and typically should not be substituted for one another.

Should an OAuth 2.0 access token be treated as opaque or self-contained by the client?

That depends on the deployment. Access tokens may be opaque, meaning the client cannot inspect them and the resource server validates them by other means, or self-contained (for example a JWT), where claims are carried within the token. In most cases the OAuth 2.0 client is intended to treat the access token as opaque and not parse its contents, since the token's structure is a contract between the authorization server and resource server and can change depending on configuration.

How does a resource server validate an OAuth 2.0 access token?

Validation approaches vary by deployment. For self-contained tokens the resource server may validate a signature and check claims such as issuer, audience, and expiry locally. For opaque tokens the resource server typically relies on an introspection interaction with the authorization server to determine whether the token is active and what it authorizes. The appropriate method depends on the token format and the profile in use.

What is the role of a refresh token in an OAuth 2.0 deployment?

A refresh token is a credential a client can use to obtain new access tokens without repeating the full authorization flow, typically when the current access token has expired. Whether refresh tokens are issued, how long they live, and whether they are rotated on use depends on the authorization server configuration and the grant in use. Because refresh tokens are sensitive, handling and storage should be treated with care.

How should scopes be used when requesting an OAuth 2.0 access token?

Scopes express the extent of access a client requests and are typically defined by the authorization server and resource server. In most deployments clients should request the minimum scopes needed for their function, following least-privilege principles. The exact scope names, their meaning, and how they map to permissions are deployment-specific rather than universally standardized.

Common misconceptions

OAuth 2.0 is an authentication protocol that verifies who a user is.

OAuth 2.0 is a delegated authorization framework, not an authentication protocol. It governs granting a client access to resources, not verifying user identity. Authentication of users is addressed by OpenID Connect, which is built as an identity layer on top of OAuth 2.0.

An access token proves the identity of the user to the client or resource server.

An access token represents a delegated authorization to access resources, not an assertion about who the user is. For user authentication claims, OpenID Connect issues an ID token, which is distinct from an access token in purpose and audience.

A signed access token is also confidential because it is protected.

Signing provides integrity and authenticity, not confidentiality. A signed self-contained token such as a JWT can typically be decoded and its claims read unless it is also encrypted. Signing and encryption are separate protections.

Best practices

Select the grant type appropriate to the client type and deployment context rather than defaulting to one flow; use flows suited to public clients where credentials cannot be kept secret.

Treat OAuth 2.0 as authorization only, and adopt OpenID Connect when you need to authenticate users, keeping ID tokens (authentication) distinct from access tokens (authorization).

Scope access tokens to the minimum access required and keep their lifetimes short, using refresh tokens where longer sessions are needed depending on your configuration.

Ensure resource servers validate tokens correctly for the token type in use, using introspection for opaque tokens and verifying signatures, expiry, audience, and issuer for self-contained tokens.

Do not rely on token signing alone for confidentiality; encrypt tokens or protect them in transit and at rest where sensitive claims are present.

Protect and, where supported, rotate or bind refresh tokens to their client to limit the impact of token theft.