OAuth 2.0, explained
OAuth 2.0 defines four roles: the resource owner (the user), the client (the app), the authorization server that issues tokens, and the resource server (the API). Instead of sharing a password, the user approves specific scopes, and the client receives an access token, often short-lived, plus an optional refresh token.
- Authorization code with PKCE (RFC 7636): the recommended flow for web, mobile and single-page apps.
- Client credentials: machine-to-machine access where no user is involved.
- Device authorization (RFC 8628): for TVs and CLIs with limited input.
The older implicit and resource owner password grants are discouraged by current OAuth security guidance and dropped from the OAuth 2.1 draft. Access tokens are typically sent as bearer tokens (RFC 6750) in the Authorization header, and may be opaque strings or JWTs.
OAuth handles authorization, not identity. OpenID Connect is the layer on top of OAuth 2.0 that adds an ID token so the client can learn who the user is. Changing scopes, token lifetimes or flows is a change your API consumers must plan for, like any other contract change.
Related terms
- JSON Web Token (JWT): A JSON Web Token (JWT, RFC 7519) is a compact, URL-safe token of signed JSON claims, widely used as an access or ID token to authenticate API calls.
- API key: An API key is a secret string a client sends with each API request to identify its application or account for authentication, quotas and billing.
- API security: API security is the practice of protecting APIs from misuse and attack with authentication, authorization, input validation, rate limits and monitoring.