What is OAuth? Delegated authorization explained for developers

OAuth is an open authorization protocol that lets a user grant a third-party application limited access to their resources on another service without ever revealing their password, by issuing the application a scoped access token instead. The modern standard, OAuth 2.0, defines several flows for obtaining that token. For nearly all applications today the recommended approach is the authorization code flow with PKCE. OAuth handles authorization; when you also need to know who the user is, OpenID Connect adds authentication on top.

Key takeaways

• OAuth delegates limited access to resources without sharing the user’s password, using scoped tokens.
• OAuth is about authorization, not authentication; OpenID Connect layers authentication on top of it.
• The authorization code flow with PKCE is the recommended flow for web, single-page, and mobile apps.
• Access tokens are short-lived API credentials; refresh tokens obtain new access tokens without re-prompting the user.
• Scopes constrain exactly what a token may do, supporting least-privilege access.
• Never put tokens in URLs where they can leak; the implicit flow is discouraged for this reason.

What problem does OAuth solve?

Before OAuth, letting one app use another service on your behalf often meant handing over your username and password, which gave the app unlimited, unrevocable access. OAuth replaces that anti-pattern with delegated authorization: the user approves specific access, and the app receives a token that represents only that grant.

This yields three practical benefits. The app never sees the user’s credentials. The access is scoped to only what is needed. And the grant can be revoked independently, without the user changing their password. That is why signing into a tool and granting it read access to your calendar or repositories relies on OAuth rather than credential sharing.

Who are the four roles in OAuth?

OAuth defines four participants, and understanding them makes every flow easier to follow:

• Resource owner: the user who owns the data and grants access.
• Client: the application requesting access on the user’s behalf.
• Authorization server: the service that authenticates the user and issues tokens.
• Resource server: the API that holds the protected resources and accepts access tokens.

In many products the authorization server and resource server belong to the same provider, but they are conceptually distinct. The client is registered ahead of time with the authorization server and receives a client identifier, and for confidential clients a secret.

Is OAuth authentication or authorization?

This distinction trips up many developers. OAuth is an authorization framework: it answers what an application is allowed to do, not who the user is. An access token proves the bearer may access certain resources, but it is not designed to tell the client the user’s identity.

OpenID Connect (OIDC) is a thin layer built on OAuth 2.0 that adds authentication. It introduces the ID token, a signed token containing verified claims about the user, and a standard userinfo endpoint. If your goal is signing users in, use OpenID Connect; if your goal is calling an API on the user’s behalf, plain OAuth authorization is enough. In practice many providers offer both together.

How does the authorization code flow with PKCE work?

The authorization code flow exchanges a short-lived authorization code for tokens through a back channel, so tokens are never exposed in the browser URL. PKCE (Proof Key for Code Exchange) hardens this against code interception and is now recommended for all client types, including single-page and mobile apps.

The steps are:

1. The client generates a random code_verifier and derives a code_challenge from its hash.
2. The client redirects the user to the authorization server with the challenge, requested scopes, and a state value.
3. The user authenticates and approves the requested access.
4. The authorization server redirects back with a one-time authorization code.
5. The client sends the code plus the original code_verifier to the token endpoint.
6. The server verifies the verifier against the earlier challenge and returns the tokens.

GET /authorize
  ?response_type=code
  &client_id=abc123
  &redirect_uri=https://app.example/callback
  &scope=read:profile
  &state=xyz
  &code_challenge=BASE64URL_SHA256
  &code_challenge_method=S256

Because only the party that created the verifier can complete the exchange, an attacker who intercepts the code alone cannot use it. Always validate that the returned state matches the one you sent to defend the callback against forgery.

What is the difference between access tokens and refresh tokens?

OAuth typically issues two kinds of tokens, and mixing them up leads to insecure designs.

The client presents the access token to the resource server, usually in an Authorization: Bearer header. When it expires, the client uses the refresh token at the authorization server to get a fresh access token without prompting the user again. Because refresh tokens are powerful, store them securely and support rotation, where each use issues a new refresh token and invalidates the old one.

What are scopes and how do they enforce least privilege?

Scopes are space-separated strings the client requests to describe the access it wants, such as read:profile or write:repo. The authorization server presents these to the user during consent and encodes the granted subset into the issued token. The resource server then enforces them per request.

Design scopes around least privilege:

• Request only the scopes the feature actually needs, not the broadest available.
• Prefer granular scopes over a single all-access scope so users can grant narrowly.
• On the resource server, verify the token carries the required scope before performing an action.

Well-designed scopes let a user grant a calendar tool read access without also granting the ability to delete events, which limits damage if a token leaks.

What are common OAuth security mistakes?

OAuth is robust when implemented to spec, but several mistakes recur:

• Using the implicit flow: it returns tokens in the URL fragment where they can leak into history and logs. Use the authorization code flow with PKCE instead.
• Skipping state validation: without it, the redirect callback is vulnerable to CSRF.
• Loose redirect URIs: accepting wildcard or unregistered redirect URIs lets attackers steal codes. Register exact URIs.
• Treating an access token as proof of identity: use an ID token from OpenID Connect for authentication, and validate its signature and claims.
• Storing tokens carelessly: keep refresh tokens out of reach of injected scripts and never embed client secrets in public clients.
• Ignoring token expiry and revocation: handle expiration gracefully and honor revocation.

Following the current best-practice guidance, code flow plus PKCE, strict redirect URIs, validated state, and careful token storage, avoids the large majority of real-world OAuth incidents.

How does a resource server validate an access token?

Issuing tokens is only half the picture; the resource server must validate every token it receives before honoring the request. There are two broad strategies, and which you use depends on the token format.

• Self-contained tokens: some access tokens are signed and carry their own claims. The resource server validates the signature against the authorization server’s published keys, then checks the expiry, audience, and issuer claims, and confirms the required scope is present.
• Opaque tokens: other tokens are random identifiers with no readable content. The resource server calls the authorization server’s introspection endpoint to ask whether the token is active and what it grants.

Regardless of format, a correct validation checks that the token has not expired, was issued by the expected authorization server, is intended for this resource server, and carries sufficient scope for the requested action. Skipping any of these checks, especially audience validation, can let a token minted for one service be replayed against another.

A useful mental model is that the access token is a bearer credential: whoever holds it can use it. That is why tokens are short-lived, transmitted only over TLS, and never logged or placed in URLs, and why refresh token rotation matters as a way to limit the damage of a leak.

Frequently asked questions

What is OAuth in simple terms?

OAuth is a protocol that lets a user grant an application limited access to their resources on another service without sharing their password.

Is OAuth authentication or authorization?

OAuth is authorization: it delegates access to resources. Authentication, proving who the user is, is added by OpenID Connect on top of OAuth.

Which OAuth flow should I use?

For virtually all modern apps, use the authorization code flow with PKCE, including single-page and mobile apps that once used the implicit flow.

What is the difference between an access token and a refresh token?

An access token is short-lived and used to call APIs, while a refresh token is longer-lived and used to obtain new access tokens without user interaction.

What are OAuth scopes?

Scopes are strings that limit what an access token can do, letting the user and server grant only the specific permissions an application needs.

Why is the implicit flow discouraged?

The implicit flow returned tokens directly in the URL, exposing them to leakage. The authorization code flow with PKCE is now recommended instead.

What does PKCE protect against?

PKCE prevents an attacker who intercepts the authorization code from exchanging it, by requiring proof of the original code verifier.