Identity term · last reviewed 2026-07-07
OAuth 2.0
Also known as: OAuth, OAuth2
OAuth 2.0 is a delegated authorization framework (RFC 6749) that lets a user grant an app scoped, time-limited access to their data on another service without sharing a password; it is authorization, not authentication.
How it works
OAuth 2.0 is a delegated authorization framework: it lets a user grant one application scoped, time-limited access to their data on another service without sharing a password. The user approves a request, and the client receives an access token it presents to the resource server (the API). The spec, RFC 6749, defines four roles: the resource owner (user), the client (app), the authorization server (issues tokens), and the resource server (holds data). The recommended flow for almost every client today is Authorization Code with PKCE; Client Credentials covers machine-to-machine.
When it matters
OAuth 2.0 matters whenever an app needs access to a resource on the user's behalf: reading a calendar, posting to an account, calling a partner API. It is the backbone of third-party integrations and the foundation OIDC builds on for authentication. If you are exposing an API for other apps to call with delegated permissions, OAuth scopes are how you model it. See OAuth 2.0 vs OIDC vs SAML.
Common misconceptions
- "OAuth logs users in." OAuth is authorization, not authentication. Using an access token to identify a user is the pseudo-authentication antipattern that OIDC was created to fix.
- "Use the Implicit grant for SPAs." Deprecated. Use Authorization Code with PKCE.
- "An access token is readable proof of identity." It is meant for the resource server and may be opaque. Do not parse it as a login.
Explained in depth