What Is OAuth? β Definition and How It Works
Learn what OAuth is, what problem delegated authorisation solves, the roles and grant types, and why it is not a login protocol.
OAuth is a framework for delegated authorisation: it lets one application access another service on a user's behalf, with the user's consent, without that application ever handling the user's password.
1. The Problem It Solves
Before it, an application wanting access to your data at another service asked for your password there. That gave it unlimited, permanent access indistinguishable from you, revocable only by changing the password.
OAuth replaces that with a scoped, revocable, expiring credential the user grants explicitly.
2. The Roles
| Role | Who it is |
|---|---|
| Resource owner | The user whose data it is |
| Client | The application requesting access |
| Authorization server | Authenticates the user and issues tokens |
| Resource server | Holds the data and accepts tokens |
The separation between the last two is what keeps the client away from credentials entirely.
3. What Consent Establishes
Three things at once: that the user agrees, what specifically is permitted through scopes, and for how long through token lifetime.
Each is a genuine improvement over sharing a password, and all three are what "delegated" means in practice.
4. The Grant Types
- Authorization code β the standard flow for applications acting for a user, with PKCE now recommended universally.
- Client credentials β machine-to-machine, with no user involved.
- Device code β for input-constrained devices, where the user authorises on a second screen.
- Refresh token β exchanges a long-lived credential for a new access token.
Older grants that handled passwords directly, or returned tokens through the browser, are deprecated because they reintroduced the problems OAuth exists to solve.
5. Scopes Are the Permission Model
A scope names what the token may do. A client should request the minimum it needs, and the resource server must enforce them β a token's scopes are only meaningful if something checks them.
Requesting broad scopes also has a practical cost: a demanding consent screen is a common reason users abandon a connection.
6. It Is Not Authentication
This is the most consequential misunderstanding. An access token proves that some authorisation was granted; it says nothing verifiable about who granted it.
Using one as proof of identity is a known vulnerability pattern. OpenID Connect layers identity on top of OAuth, adding an ID token designed for exactly that β and it is the correct choice when the requirement is login.
7. Practical Notes for Clients
- Verify the
stateparameter on return, without exception. - Use PKCE, including for confidential clients.
- Store refresh tokens more carefully than access tokens.
- Handle expiry proactively rather than reacting to a
401. - Never place tokens in URLs, logs, or error reports.
8. Summary
OAuth is delegated authorisation: scoped, expiring, revocable access granted by a user to an application without sharing credentials.
Its roles separate the client from the authentication step entirely, its scopes bound what a token can do, and it answers what an application may access β never who the user is, which is OpenID Connect's job.