OAuth 2.0 (Open Authorization 2.0)

Q: What's the difference between a scope and a permission?

Scope is what the *client* is asking for. Permission is what the user actually grants and what the resource server enforces. They overlap but aren't synonyms.

Key points

OAuth is about authorization (delegated access), not authentication.
Core artifacts: access token (short-lived, used to call APIs) and refresh token (long-lived, used to mint new access tokens).
Authorization Code flow with PKCE is the modern default for web, mobile, and SPA clients.
OAuth 2.1 consolidates a decade of best practices and deprecates the implicit and password grant flows.
For authentication, layer OpenID Connect on top — OAuth alone is the wrong tool.

What is OAuth 2.0?

OAuth 2.0 is an open standard (RFC 6749) for delegated authorization. It lets a user say "yes, this third-party app can read my Google Calendar" without ever handing that app their Google password. The app gets a scoped, time-limited access token; the user's credentials stay with the identity provider.

OAuth is not a login protocol. It does not tell your application who the user is in a trustworthy way. For that you want OpenID Connect, which builds an identity layer on top of OAuth.

How OAuth works

The recommended flow for almost every modern client is the Authorization Code flow with PKCE:

Your app (the client) sends the user to the authorization server's /authorize endpoint with a list of requested scopes.
The user authenticates with the authorization server (often the IdP) and approves the scopes.
The authorization server redirects back with a short-lived authorization code.
Your app's backend exchanges the code + PKCE verifier at the /token endpoint for an access token and (optionally) a refresh token.
Your app calls the resource server's APIs with Authorization: Bearer <access_token>.

Access tokens are typically opaque to the client (the resource server validates them via introspection or as JWTs). They are short-lived (minutes to an hour) and refreshed using the refresh token, which is long-lived but bound to the client.

When buyers care about OAuth

OAuth is foundational whenever your app needs to:

Let users sign in with a third-party account (combined with OIDC).
Integrate with third-party APIs on the user's behalf (Slack, Salesforce, GitHub, Google).
Protect your own APIs that are called from mobile apps, single-page apps, partners, or AI agents.
Issue short-lived, scoped tokens to machines and AI agents (see AI Agent Identity).

OAuth grant types

Authorization Code (+ PKCE) — the default for almost everything.
Client Credentials — machine-to-machine, no user involved.
Device Authorization Grant — TVs, CLIs, devices without a browser.
Refresh Token — used to mint new access tokens.
Implicit — deprecated. Don't use.
Resource Owner Password Credentials (ROPC) — deprecated. Don't use.

OAuth 2.0 vs OAuth 2.1

OAuth 2.1 is not a new protocol — it's a consolidation of best practices that have emerged since 2012. The major changes:

PKCE required for all clients using the Authorization Code flow.
Implicit flow removed.
ROPC flow removed.
Exact redirect URI matching required.
Refresh tokens for public clients must be sender-constrained or rotated.

If you're building new, target 2.1.

Common pitfalls

Using OAuth for authentication. Layer OIDC on top.
Storing access tokens in localStorage. Vulnerable to XSS. Prefer httpOnly cookies or in-memory storage with refresh rotation.
Long-lived access tokens. Defeats the point. Keep them short and rely on refresh tokens.
Wide scopes. Ask for the minimum scope you need. "All access" is a red flag for buyers.

FAQ

Is OAuth 1.0 still used?

Only in a handful of legacy APIs (some older Twitter / X endpoints). New work should always be OAuth 2.0 or 2.1.

What's the difference between a scope and a permission?

Scope is what the client is asking for. Permission is what the user actually grants and what the resource server enforces. They overlap but aren't synonyms.