OAuth 2.0 — Glossary

OAuth 2.0 is an authorization framework that lets an application get limited access to a user's data on another service through tokens, without ever handling the user's password. It is defined in RFC 6749 from October 2012, which replaced OAuth 1.0. Current security guidance is RFC 9700, published in January 2025 as BCP 240, and it updates RFC 6749.

How it works

RFC 6749 names four roles. The resource owner is usually the user. The client is the app that wants access. The authorization server authenticates the user and issues tokens. The resource server hosts the protected data and accepts access tokens.

The most common flow is the authorization code grant:

Authorize: the client redirects the user to the authorization endpoint with response_type=code, client_id, redirect_uri, scope and state.
Consent: the user signs in at the authorization server and approves the scopes.
Callback: the server redirects back to the registered redirect URI with a short-lived code and the same state.
Exchange: the client sends the code to the token endpoint in a form-encoded POST with grant_type=authorization_code, and receives an access token, a token_type, expires_in and optionally a refresh token.
Call the API: the client sends Authorization: Bearer <token> to the resource server.

The authorization endpoint and token endpoint must use TLS. A code must expire quickly, with a maximum lifetime of 10 minutes recommended, and may be used only once.

RFC 6749 defined four grant types: authorization code, implicit, resource owner password credentials and client credentials. RFC 9700 says the password grant must not be used and the implicit grant should not be used. OAuth 2.1 omits both grants, but as of October 2026 it is still an IETF draft, not an RFC.

A Python script built these two requests. The PKCE verifier and challenge are the RFC 7636 test vector, and the script confirmed the SHA-256 result matches.

https://auth.example.com/authorize?response_type=code&client_id=s6BhdRkqt3&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb&scope=read&state=xyz&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcb&client_id=s6BhdRkqt3&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk

Is OAuth 2.0 authentication or authorization?

OAuth 2.0 is authorization: it answers what an app may do, not who the user is. RFC 6749 treats an access token as usually opaque to the client. Apps that need to sign users in use OpenID Connect, which is a simple identity layer on top of OAuth 2.0 and adds an ID token.

What is PKCE?

PKCE, Proof Key for Code Exchange, is an extension in RFC 7636, pronounced "pixy", that ties an authorization code to the client that requested it. The client makes a random code_verifier of 43 to 128 characters, sends its SHA-256 hash as code_challenge with method S256, and later proves possession by sending the verifier. RFC 9700 requires PKCE for public clients and recommends it for confidential ones.

Common pitfalls

Skipping the state check: if the callback does not compare state to the value stored for that browser session, an attacker can inject their own code. RFC 6749 requires CSRF protection and recommends the state parameter for it.
Loose redirect URI matching: prefix or wildcard matching leaks codes to attacker pages. RFC 6749 and RFC 9700 call for comparing against the registered URI by exact string match. The one exception is RFC 8252, which lets native apps vary the port on loopback redirect URIs.
Using an access token as proof of login: it proves nothing about who presented it. Validate an OpenID Connect ID token instead.
Secrets in browser or mobile code: such clients are public and cannot keep a client_secret. Use the authorization code grant with PKCE and no embedded secret.
Implicit and password grants in new code: RFC 9700 rules out both, as noted above. The password grant gives the client the user's credentials, which is what OAuth exists to avoid.

Related terms

JWT — a common format for access and ID tokens, though RFC 6749 does not require it
API key — a static credential, unlike a scoped and expiring OAuth token
CSRF — the attack the state parameter defends against
HTTPS — required for OAuth endpoints
TLS — the encryption layer that protects tokens in transit