What Is OAuth 2.0? – Definition and How It Works

Learn what OAuth 2.0 delegates, which grant types are current, and why it is authorisation rather than authentication.

OAuth 2.0 is a delegated authorisation framework. It lets an application obtain limited access to a resource on a user's behalf, without the user handing over their password.

1. Authorisation, Not Authentication

The distinction that causes the most confusion.

OAuth 2.0 answers: may this application access this resource? It issues access tokens with scopes.

It does not answer: who is this user? Using an access token as proof of identity is a known anti-pattern, because a token says what may be accessed, not who is present.

OpenID Connect is the identity layer built on top of OAuth 2.0, adding an id_token that does make identity claims. If you need to know who the user is, that is the thing to use.

2. The Roles

3. The Grant Types That Are Current

Authorization Code with PKCE — the default for essentially everything now, including single-page and mobile apps. The user authenticates at the authorization server, the client receives a short-lived code, and exchanges it for tokens. PKCE binds the exchange to the original requester, preventing code interception.

Client Credentials — machine-to-machine, with no user involved. The client authenticates as itself. This is the grant most API integrations use.

Refresh Token — exchanges a refresh token for a new access token, so access tokens can be short-lived.

Device Authorization — for devices without a browser or keyboard.

Two grants are deprecated and should not be used in new work: the Implicit grant, which returned tokens in a URL fragment, and the Resource Owner Password Credentials grant, which required the client to handle the user's password — defeating the purpose of the framework.

4. The Authorization Code Flow, Concretely

1. Client → browser → authorization server
   /authorize?response_type=code&client_id=…&redirect_uri=…
   &scope=read:data&state=<csrf>&code_challenge=<hash>&code_challenge_method=S256

2. User authenticates and consents

3. Authorization server → redirect_uri?code=<code>&state=<csrf>

4. Client → authorization server  (back channel, POST)
   grant_type=authorization_code&code=<code>&code_verifier=<original>

5. Response: {access_token, refresh_token, expires_in, token_type: "Bearer"}

state protects against CSRF and must be verified on return. code_verifier is the PKCE secret that proves the same client that started the flow is finishing it.

5. Scopes Are the Access Boundary

Scopes limit what a token can do. Requesting the minimum needed is both good practice and a smaller blast radius if the token leaks.

For anyone integrating with an API, the useful discipline is reading which scopes actually exist rather than requesting a broad one because it is convenient — and storing tokens according to their scope's sensitivity.

6. What This Means for Data Collection

An official API with OAuth is almost always the right answer when it exists. It is the sanctioned, rate-limited, licensed route, and it eliminates the entire fragile business of parsing HTML.

Practical notes:

• Client credentials is usually the grant for a data pipeline, since no end user is involved.
• Handle refresh under a lock, so concurrent workers do not race and invalidate each other's token.
• Persist a rotated refresh token immediately; losing it means re-authenticating from scratch.
• Store client secrets in a secret manager, never in code or an environment file committed anywhere.
• Respect the scopes granted — using a token beyond its intended purpose breaches the terms it was issued under.

7. Common Implementation Errors

• Not verifying state on the redirect.
• Using the deprecated implicit or password grants.
• Storing tokens in local storage where XSS can read them.
• Treating an access token as an identity assertion.
• Requesting far broader scopes than needed.
• Not handling token expiry, so requests fail mid-run.

8. Summary

OAuth 2.0 delegates limited, scoped access to a resource without sharing the user's password, using Authorization Code with PKCE for user-present flows and Client Credentials for machine-to-machine access.

It authorises rather than authenticates — OpenID Connect is the identity layer — and for data collection an OAuth-protected official API is nearly always preferable to scraping, provided refresh is serialised under a lock and client secrets live in a secret manager.

Potential Related Glossary

• Web Crawling
• Parsing
• Data Structure
• Concurrency vs Parallelism