OAuth 2.0
By IETF
0 is an industry-standard authorization protocol that lets a user grant a third-party application limited access to their resources on another service without sharing their password. Defined by the IETF, it works through access tokens…
Definition
OAuth 2.0 is an industry-standard authorization protocol that lets a user grant a third-party application limited access to their resources on another service without sharing their password. Defined by the IETF, it works through access tokens issued after an authorization flow, and it underlies most "log in with" and API access-delegation features used across web, mobile, and cloud applications today.
Overview
OAuth 2.0 solves the problem of letting one application act on a user's behalf against another service, such as a photo-printing app that needs to read a user's cloud storage files, without the user handing over their actual password to that photo-printing app. Before OAuth existed, this kind of delegation typically meant sharing credentials directly, which gave the third party far more access than needed and no easy way to revoke it later. OAuth introduces a token-based model where access is scoped, time-limited, and revocable independently of the user's actual login credentials. Mechanically, OAuth 2.0 defines several roles: the resource owner, the user who owns the data; the client, the application requesting access; the authorization server, which authenticates the user and issues tokens; and the resource server, which holds the protected data and accepts the token as proof of access. A client redirects the user to the authorization server, the user approves a requested scope of access, and the authorization server returns an authorization code that the client exchanges for an access token, and optionally a refresh token, which the client then presents to the resource server on every API call. The protocol defines several grant types for different scenarios, including the authorization code flow for apps with a backend, and the client credentials flow for machine-to-machine access. OAuth 2.0 is often confused with authentication, but it is fundamentally an authorization protocol; it proves what an application is allowed to do, not who the user is. That distinction is why OpenID Connect was built as an identity layer on top of OAuth 2.0, adding an ID token that actually asserts the user's identity. OAuth also differs from SAML, an older XML-based standard more common in enterprise single sign-on, in that OAuth uses lightweight JSON tokens better suited to mobile and API-driven architectures. In practice, OAuth 2.0 powers social login buttons, third-party app integrations that connect to services like cloud storage or calendar APIs, and the token-based access control used by nearly every modern public API, including those from major cloud and SaaS providers. Backend services also use its client credentials flow purely for service-to-service authorization without any human user involved. The protocol's flexibility is also its main risk: because it defines a family of flows rather than one fixed procedure, implementers can misconfigure redirect URIs, use insecure legacy grant types, or omit token expiration handling, all of which have led to real vulnerabilities in poorly built OAuth integrations. It also does not specify how a user is authenticated in the first place, which is why OpenID Connect is typically layered on top when actual identity verification is required.
Specification
- Scoped, time-limited access tokens instead of shared password credentials
- Multiple grant types for web, mobile, and machine-to-machine scenarios
- Separation of resource owner, client, authorization server, and resource server roles
- Refresh tokens allow long-lived access without re-prompting the user
- Widely adopted for social login and third-party API integrations
- Extended by OpenID Connect to add a standardized identity layer
- Revocable access that does not require changing the user's password