OAuth 2.0 is an authorization framework that lets a client application obtain limited access to a protected resource on behalf of a resource owner, by means of access tokens issued by an authorization server instead of the owner’s password. In identity & access management it is the dominant standard for delegated API access, defined in RFC 6749 with bearer token usage in RFC 6750.
OAuth 2.0 answers the question “what may this application do”, not “who is this user”. Authentication is layered on top by OpenID Connect, which adds an ID token. Confusing the two is one of the most persistent sources of design flaws in systems that use OAuth.
Roles and tokens in OAuth 2.0
OAuth 2.0 separates the parties involved in access into four defined roles. This separation is what allows a user to grant an application access without revealing credentials to it.
| Role | Description | Example |
|---|---|---|
| Resource owner | The entity that can grant access, usually a user | A person with a calendar account |
| Client | The application requesting access | A scheduling app |
| Authorization server | Authenticates the owner and issues tokens | The identity provider’s token service |
| Resource server | Hosts the protected API and validates tokens | The calendar API |
The central artifact is the access token, a credential representing granted permissions, typically valid for 5 to 60 minutes. It may be an opaque string checked through token introspection or a signed JSON Web Token validated locally. A longer-lived refresh token lets the client obtain new access tokens without involving the user again.
Permissions are expressed as OAuth scopes, such as calendar.read. The user consents to the requested scopes, and the resource server must enforce them. Requesting broad scopes violates least privilege and enlarges the damage if a token leaks.
Grant types and when to use them
A grant type is the method a client uses to obtain tokens. The original specification defined several, but current best practice, consolidated in the OAuth 2.0 Security Best Current Practice and the draft OAuth 2.1, removes the insecure ones.
| Grant type | Typical client | Current recommendation |
|---|---|---|
| Authorization code with PKCE | Web, mobile and single-page apps | Default choice for any user-facing client |
| Client credentials | Server-to-server services | Recommended for machine access without a user |
| Device authorization | TVs, consoles, command-line tools | Recommended for input-constrained devices |
| Refresh token | Any client with offline access | Use with rotation or sender constraint |
| Implicit | Legacy browser apps | Deprecated; tokens exposed in URLs |
| Resource owner password | Legacy first-party apps | Deprecated; client sees the password |
PKCE, Proof Key for Code Exchange, protects the authorization code flow. The client creates a random code verifier, sends its SHA-256 hash with the authorization request, and proves possession of the verifier when redeeming the code. An attacker who intercepts the code cannot exchange it without the verifier.
How the authorization code flow works
- The client redirects the user’s browser to the authorization endpoint with client_id, redirect_uri, scope, state and the PKCE code challenge.
- The authorization server authenticates the user, possibly with MFA, and asks for consent.
- The server redirects back to the registered redirect_uri with a short-lived authorization code.
- The client verifies the state value and sends the code with the code verifier to the token endpoint over a back channel.
- The server returns an access token and optionally a refresh token, which the client presents to the resource server.
The state parameter protects against cross-site request forgery on the redirect, and exact redirect URI matching prevents an attacker from diverting codes to a domain they control. Authorization codes are single-use and usually expire within about a minute.
OAuth 2.0 compared with related standards
OAuth 2.0 is frequently mentioned alongside other identity protocols, and each solves a different problem. The table separates authorization, authentication and federation.
| Standard | Purpose | Token format | Typical use |
|---|---|---|---|
| OAuth 2.0 | Delegated authorization | Access token, any format | API access for apps |
| OpenID Connect | Authentication on top of OAuth 2.0 | ID token as JWT | Login with an identity provider |
| SAML 2.0 | Federated authentication and SSO | XML assertion | Enterprise web SSO |
| OAuth 1.0a | Delegated authorization with signed requests | Token plus signatures | Legacy APIs |
Using an OAuth access token as proof of login is a classic flaw: a token issued to one application can be replayed against another that accepts it. OpenID Connect fixes this with an ID token containing an audience claim that names the intended client.
Security risks and best practices
Most OAuth incidents result from implementation and configuration errors rather than flaws in the framework itself. Standard access tokens are bearer tokens: whoever holds one can use it, so protecting tokens is critical.
| Weakness | Consequence | Mitigation |
|---|---|---|
| Loose redirect URI matching | Codes or tokens sent to attacker domains | Register and match exact URIs |
| Missing PKCE | Authorization code interception | Require PKCE for all clients |
| Overly broad scopes | Large blast radius after token theft | Request minimal scopes |
| Long-lived tokens | Extended misuse window | Short expiry and refresh token rotation |
| Tokens in browser storage | Theft through XSS | Backend-for-frontend pattern, HttpOnly cookies |
| Consent phishing | Users grant malicious apps access | Admin consent policies and app verification |
Stronger deployments use sender-constrained tokens through DPoP or mutual TLS, so a stolen token is useless without the client’s private key. Token revocation endpoints and short token expiration limit exposure further.
A plain-language summary
OAuth 2.0 is like a valet key for a car. The owner gives the valet a key that can start the car and park it, but cannot open the trunk or glove box. The valet never receives the owner’s full key.
In the same way, when an app asks to read a person’s calendar, the person approves it on the calendar provider’s own page. The app receives a limited, temporary pass instead of the password, and the person can cancel that pass at any time without changing the password.
An example from practice
A company builds a reporting tool that needs to read files from employees’ cloud storage. The developers register the tool with the company’s identity provider and implement the authorization code flow with PKCE, requesting only a read-only files scope. Access tokens expire after 30 minutes, and refresh tokens rotate on every use.
A nightly export job that runs without users uses the client credentials grant with its own narrowly scoped service registration. During a later security review, a leaked log file is found to contain an expired access token. Because of the short lifetime and read-only scope, the token can no longer be used and could never have modified data, so the review records the issue as low impact and the team removes token values from logging.