Chapter 1. What is OAuth 2.0 and why should you care?
OAuth 2.0 is a widely adopted framework for securing and connecting web APIs by delegating limited access to applications without sharing user passwords. Instead of impersonation, it uses access tokens that represent specific, bounded rights granted by the resource owner, enabling websites, native, and mobile apps to act on a user’s behalf across organizational boundaries. The core actors are the resource owner, client, protected resource (API), and authorization server, and the token acts like a revocable “valet key,” scaling from small apps to internet-scale platforms while often remaining invisible to end users.
Prior to OAuth, common integration patterns—replaying credentials, asking users for other services’ passwords, universal developer keys, or ad hoc service-specific passwords—led to impersonation, excessive and persistent access, insecure secret storage, and high-impact breaches. OAuth replaces these with a user-mediated delegation flow: a client sends the user to an authorization server to approve specific scopes; the client then obtains an access token and presents it to the protected resource. This enables narrowly scoped, time-limited access that users can revoke, and many deployments pair this with user-driven decisions (such as Trust On First Use) alongside whitelist/blacklist policies to balance flexibility with control.
OAuth 2.0 concentrates on how to get and use tokens for authorization; it is not an authentication protocol, does not define token formats, user-to-user delegation, or built-in cryptography, and relies on secure transport and complementary technologies for those needs. Its design assumes many clients and fewer servers, pushing complexity and security responsibilities to authorization and resource servers while keeping clients simpler—limiting blast radius if a client is compromised but demanding strong server-side practices and clear profiles to avoid insecure or incompatible choices. With these trade-offs understood, OAuth’s modular, delegation-first model forms a solid foundation for modern, API-centric security.
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 (usually a user) grant a client application limited access to a protected resource (an API) using access tokens—without sharing passwords. Think of the token as a “valet key” that allows only specific, limited actions.Why do we need OAuth—what was wrong with sharing passwords?Older patterns relied on clients replaying user passwords or using powerful developer keys. These approaches enable impersonation, expose credentials to theft, are hard to revoke safely, don’t cross organizational boundaries well, and often grant far more access than needed.Who are the main actors in OAuth?- Resource owner: the party that controls the data (typically the user). - Client: the application that wants access to the API. - Protected resource: the API holding the data or actions. - Authorization server: the service that authenticates the user and issues access tokens to clients.How does OAuth work at a high level?The client sends the user to the authorization server to authenticate and approve requested permissions (scopes). If approved, the authorization server issues an access token to the client. The client uses that token to call the protected resource. The user’s credentials are never shared with the client.What are access tokens and scopes?An access token represents the delegated right for a client to access an API. Scopes describe the specific permissions (for example, read-only vs. write). Tokens are typically short-lived and limited in capability, reducing risk compared to passwords.Is OAuth an authentication protocol?No. OAuth conveys authorization (delegation), not identity. It tells an API that “someone authorized this client to do X,” not who that someone is. To authenticate users (learn who they are), you need additional layers, such as OpenID Connect.Does OAuth require HTTPS/TLS?Yes, in practice. OAuth 2.0 commonly uses bearer tokens and does not define message signatures, so it relies on TLS to protect tokens in transit. Using OAuth outside HTTP/TLS requires explicit profiles that map OAuth semantics to other protocols.What doesn’t OAuth 2.0 define?- A token format (the token is opaque to clients). - How to process authorizations inside the API. - User-to-user delegation. - New cryptographic methods. - A single, universal flow (it’s a framework with multiple flows for different use cases). Related specs like JWT and token introspection exist but are outside the core.What are the main pros and cons of OAuth 2.0?Pros: strong delegation with least privilege; no password sharing; revocable, scoped, time-limited tokens; user choice and consent; simpler clients with complexity centralized on servers. Cons: more responsibility and attack surface on authorization/resource servers; optionality can create interoperability gaps and insecure configurations if misused.How does OAuth enable user-driven security (TOFU)?With Trust On First Use, unknown apps can prompt users for consent the first time, and the system can remember the decision. Combined with policy-driven whitelists/blacklists, this “graylist” approach balances flexibility and security while presenting decisions in terms of functionality users understand.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
OAuth 2 in Action ebook for free
