OAuth 2.0 is an authorization framework. It lets a client obtain limited access to a protected resource. It is not, by itself, a protocol for establishing an end user’s identity to a client.
The actors
| Actor | Responsibility |
|---|---|
| Resource owner | Can authorize access to a protected resource. |
| Client | Requests access and uses a token. |
| Authorization server | Processes authorization and issues tokens. |
| Resource server | Hosts the protected API and validates access. |
An organization might operate several of these roles in one service. Their responsibilities remain distinct.
An illustrative authorization-code interaction
- A document-printing application redirects a user to the authorization server with a narrowly defined access request.
- The server handles authentication and authorization according to its policies.
- The browser returns an authorization code to the registered client callback.
- The client exchanges the code and the required proof for tokens.
- The client presents an access token to the document API.
PKCE binds the authorization request to a code verifier presented at the token endpoint. It helps protect against authorization-code interception and injection attacks; it does not replace every other required validation.
Scopes and enforcement
A scope such as documents.read describes requested or granted access according to the API’s contract. The resource server still needs to check the token’s validity and the actual resource and action.
A token for document reading must not become permission to read every tenant’s documents simply because the scope has the same name.
Access tokens can be opaque or structured. Their format is a deployment choice; clients should not assume every access token is a JWT.
Use current security guidance
Use maintained protocol libraries and the applicable security profile. The OAuth Security BCP advises against the implicit grant and prohibits use of the resource owner password credentials grant. Exact redirect URI handling, PKCE, token protection, and client type all matter.
For application sign-in, continue with OpenID Connect. For software acting without a user, see workload access.
Go deeper
| Topic | Article |
|---|---|
| Which grant and which client authentication to use | Grant types and clients |
| What each authorization server endpoint does | Authorization server endpoints |
| How clients and APIs discover each other | Discovery and metadata |
| What is inside a token | Token claims and self-contained vs. opaque tokens |
| How an API should accept tokens | Protecting an API as a resource server |
| Binding tokens to the client | DPoP |
| Protecting and enriching the authorization request | PAR and JAR, RAR |
| Device flow, token exchange, mTLS, OAuth 2.1 | Advanced OAuth |
| What can go wrong | Threats and mitigations |
| Browser and mobile architectures | Backend for frontend, native and mobile apps |
References
- OAuth 2.0, RFC 6749.
- PKCE, RFC 7636.
- OAuth Security BCP, RFC 9700.
- Bearer Token Usage, RFC 6750.
- OAuth.net, a community index of OAuth specifications maintained by specification authors.