What is OAuth 2.0, and what is it actually for?

OAuth 2.0 is an authorization framework: it lets a user grant an application limited access to their resources — an API, a calendar, a repository — without sharing their password. It is defined in RFC 6749, with extensions for specific situations.

It is not a login protocol, even though most "sign in with..." buttons use it. Login is what OpenID Connect adds on top. This article covers what OAuth itself does.

The four roles

The client never sees the user's password. It gets a token from the authorization server, and presents that token to the resource server.

Tokens and scopes

• Access token — a credential with a scope and an expiry. It travels in the Authorization: Bearer ... header (RFC 6750).
• Refresh token — a long-lived credential the client can exchange for new access tokens without asking the user again.
• Scopes — strings that describe what the token may do: read:calendar, repo, openid profile email. The client asks for scopes; the user approves them; the token carries them.

Tokens are usually opaque to clients. They can be JWTs that the resource server verifies locally, or random strings that the resource server introspects. Both are valid designs.

The flows (grant types) that matter

OAuth defines several ways to obtain a token. The ones worth knowing in 2026:

Authorization code, with PKCE. The user is redirected to the authorization server, approves, and the client exchanges a short-lived code for tokens. Every web, mobile and single-page app should use this, with PKCE (RFC 7636) for public clients.

Client credentials. No user involved: a service authenticates with its own client ID and secret and gets a token for machine-to-machine calls.

Device code. For devices without a browser, such as CLIs and TVs. The device shows a code, the user types it on another device, and the device polls for the token. See OAuth device flow.

Refresh token. Exchanges a refresh token for a new access token, so long-lived apps do not interrupt the user every hour.

Two older flows are being retired in practice: implicit (tokens in the URL fragment) and resource owner password credentials (the client collects the password directly). The OAuth 2.1 draft removes both; use authorization code with PKCE instead.

What OAuth does not do

• It does not authenticate users. An access token proves a grant, not a person. Use OpenID Connect for login.
• It does not define user attributes. OAuth has no standard userinfo; OIDC does.
• It does not protect against a badly written client. Tokens leak through logs, referrers and misconfigured redirect URIs; the specification cannot fix that.

Common mistakes

1. Using the implicit flow for a single-page app. The tokens end up in the URL and browser history. Use authorization code + PKCE.
2. Skipping the state parameter. Without it, the callback can be forged (login CSRF).
3. Over-broad scopes. A token that can do everything defeats the point of delegation.
4. Long-lived access tokens. Prefer short access tokens with refresh, so revocation is meaningful.
5. Storing tokens in localStorage. Any XSS becomes token theft. Prefer httpOnly cookies with the BFF pattern, or in-memory storage with refresh.

OAuth and OIDC together

In a modern stack:

• OAuth 2.0 issues access tokens for APIs.
• OIDC adds an ID token with the user's identity, so the same authorization server can also sign the user in.

That is why an identity provider like Casdoor speaks both: OAuth for API access, OIDC for browser and mobile login, plus SAML for enterprise applications. See OAuth vs OIDC and what OpenID Connect is.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.