OAuth 2.0 is a widely adopted security framework that lets users delegate limited access to their data without sharing passwords, enabling applications to call web APIs securely across websites, mobile, and native apps. It replaces fragile approaches like credential replay and universal developer keys with purpose-built tokens that act like a “valet key,” granting only the specific rights needed for a task. Designed for today’s API-driven ecosystem, OAuth balances security and usability, making cross-service integration practical for everything from consumer apps to enterprise systems.
At its core, OAuth 2.0 involves four main roles: the resource owner (user), the client (app), the protected resource (API), and the authorization server. The client sends the user to the authorization server to authenticate and approve requested scopes; in return, the client obtains an access token that the API can validate and enforce according to the user’s delegated permissions. This design keeps user credentials away from clients, limits access by scope and time, supports revocation, and scales beyond browser sessions and HTTP Basic Auth to fit non-interactive API calls—while still enabling user choice through consent and patterns like Trust On First Use when appropriate.
OAuth 2.0 delivers strong delegation but has boundaries and trade-offs. It is not an authentication protocol by itself, does not define token formats, cryptographic methods, or user-to-user delegation, and is intended to run over HTTPS. Its flexibility and modularity power many use cases but can create incompatibilities or insecure implementations if options are misapplied. Complexity is intentionally shifted from clients to authorization and resource servers, concentrating risk where it’s easier to harden. Used correctly, OAuth 2.0 provides a focused, extensible foundation that other technologies can build upon to form complete, secure systems.
An OAuth authorization dialog from the exercise framework for this book
Connecting the client on behalf of the resource owner
Copy the resource owner’s credentials without asking
Ask for the resource owner’s credentials, and replay them
Use a universal developer key, and identify the user on whose behalf you’re (allegedly) acting
A service-specific password that limits access
The OAuth authorization server automates the service-specific password process
The OAuth process, at a high level
Different levels of trust, working in parallel
Notional relative numbers of components in an OAuth ecosystem
FAQ
What is OAuth 2.0 in simple terms?
OAuth 2.0 is a delegation protocol that lets a resource owner allow a third‑party application to access a protected HTTP service on their behalf using tokens, without sharing passwords. Think of the token like a “valet key” that grants limited, revocable access instead of full control.Why do we need OAuth instead of sharing passwords?
Sharing passwords forces clients to impersonate users, store replayable credentials, and creates high risk if a client is compromised. It also fails across different security domains and breaks with modern login methods. OAuth replaces this with scoped, time‑limited, revocable tokens that represent delegated access, not the user’s primary credential.Who are the main actors in OAuth?
- Resource owner: typically the end user who can delegate access to their data or actions.- Client: software that wants to call the protected API on the user’s behalf.
- Protected resource: the API or service holding the data/actions.
- Authorization server: issues access tokens to clients after the resource owner authorizes them.
OAuth 2 in Action ebook for free
