OAuth 2.0 is an open standard for delegated authorization that lets a user grant a third-party application limited access to their resources on another service, without sharing their password. It’s the technology behind "allow this app to access your calendar/photos/contacts," and it underpins much of modern web, mobile, and API access.

The problem OAuth solves is delegation done safely. Before OAuth, granting an app access to your data on another service often meant handing over your password, dangerous and coarse. OAuth replaced that with scoped, revocable, token-based access that never exposes the credential.

How OAuth 2.0 works

OAuth defines roles and a flow. The resource owner (the user) authorizes access; the client (the third-party app) requests it; the authorization server authenticates the user and issues tokens; the resource server holds the data and accepts the tokens. In a typical flow, the app redirects the user to the authorization server, the user consents to a specific scope of access, and the app receives an access token it presents to the resource server to act within that scope. Tokens are limited and revocable, so access is bounded and can be withdrawn.

Key concepts

• Scopes: the specific, limited permissions being granted (e.g., read calendar, not full account).
• Access tokens: short-lived credentials the client uses to access resources.
• Refresh tokens: used to obtain new access tokens without re-prompting the user.
• Grant types / flows: different flows for different app types (authorization code flow for web/mobile apps, client credentials for machine-to-machine, etc.).

The authorization code flow (ideally with PKCE) is the recommended flow for most user-facing apps today.

Authorization, not authentication

A crucial and often-misunderstood point: OAuth 2.0 is an authorization framework, not an authentication protocol. It’s about granting access to resources, not proving who the user is to the client app. Using OAuth alone to "log in" leads to subtle security problems, which is exactly why OpenID Connect was created, an identity layer on top of OAuth 2.0 that adds proper authentication. If you need "sign in with," you want OIDC; if you need "let this app access that resource," you want OAuth.

Security considerations

OAuth is powerful but must be implemented carefully. Best practices include using the authorization code flow with PKCE (not the deprecated implicit flow), validating redirect URIs strictly, keeping tokens short-lived and transmitted only over HTTPS, requesting the minimum scopes needed (least privilege), and protecting tokens from theft (a stolen token grants the access it carries). Misconfigured OAuth is a recurring source of vulnerabilities, so following current best-practice guidance matters.

Where OAuth fits

OAuth 2.0 is foundational to modern identity and API ecosystems: it enables third-party app access, powers OpenID Connect (and thus much of social login and SSO), and secures API and microservice access through token-based authorization. For developers and architects, understanding OAuth is essential to building and securing modern applications, and understanding its boundary with OIDC is essential to using it correctly.

OAuth flows explained

OAuth defines several "grant types" (flows) because different application types have different security needs. The authorization code flow (ideally with PKCE (Proof Key for Code Exchange)) is the recommended flow for web and mobile apps: the app receives a short-lived authorization code, then exchanges it server-side (or with PKCE protection) for tokens, keeping tokens out of the browser’s reach. The client credentials flow is for machine-to-machine access where no user is involved, authenticating the app itself. The older implicit flow returned tokens directly in the browser and is now deprecated because of its security weaknesses. Choosing the right flow for the app type is one of the most important OAuth security decisions, and modern guidance strongly favors authorization code with PKCE for anything user-facing.

The evolution toward OAuth 2.1

OAuth 2.0 has accumulated best practices and security lessons over the years, and the community has been consolidating them into OAuth 2.1: not a radical change, but a cleanup that bakes in current best practice: mandating PKCE for authorization code flows, removing the insecure implicit and password grant flows, and tightening redirect-URI handling. The direction reflects a broader theme in OAuth’s maturation: the flexible original spec left room for insecure choices, so the ecosystem has steadily narrowed toward the safe patterns. For anyone implementing OAuth today, following current best-practice guidance (effectively the 2.1 direction) matters more than the version number, the goal is to avoid the deprecated flows and configurations that caused real-world breaches.

Frequently asked questions

What is OAuth 2.0?

An open standard for delegated authorization that lets apps access a user’s resources on another service without sharing the password.

Is OAuth 2.0 authentication or authorization?

Authorization. It grants scoped access to resources. For authentication ("sign in with"), OpenID Connect adds an identity layer on top.

What is an OAuth access token?

A short-lived, scoped credential the client presents to access the user’s resources within the granted permissions.

What is a scope in OAuth?

The specific, limited set of permissions a user grants an app, supporting least-privilege access.

What’s the recommended OAuth flow?

The authorization code flow with PKCE for user-facing apps; client credentials for machine-to-machine.

Related: OpenID Connect (OIDC) · OIDC vs. OAuth 2.0 · Token-Based Authorization (JWT) · Authorization · API Security · Single Sign-On (SSO)