What Is OAuth 2.0?
OAuth 2.0 is an authorization framework, defined in RFC 6749, that lets a third-party application obtain limited access to a user's resources hosted on another service (like Google Drive or GitHub) without the user handing over their username and password directly to that third-party app. Instead, the user grants specific, scoped permissions through the service that owns the data, and the third party receives a token it can present to prove it was granted that access.
Cricket analogy: Think of a franchise like Mumbai Indians issuing a specific accreditation pass to a broadcast crew instead of handing them the team dressing-room key — the pass lets the crew film practice sessions without giving them access to team strategy meetings.
Why OAuth 2.0 Replaced the Password-Sharing Model
Before OAuth became standard, integrating two services meant the classic 'password anti-pattern': you typed your Gmail or Twitter password directly into a third-party app so it could act on your behalf. That approach had no way to limit what the app could do, no way to revoke access without changing your password everywhere it was reused, and it trained users to hand out credentials to any app that asked — a habit phishers exploited relentlessly. OAuth 2.0, finalized in 2012, replaced this with delegated, revocable, scoped tokens issued by the service itself.
Cricket analogy: This mirrors why cricket boards stopped letting outside commentary teams use the groundstaff's master gate key — now they use match-day credentials that can be deactivated after a single Test without changing every lock at the stadium.
# Simplified OAuth 2.0 exchange (authorization code grant)
# 1. Client redirects the user's browser to the authorization server
GET /authorize?response_type=code
&client_id=photo_app_123
&redirect_uri=https://photoapp.example.com/callback
&scope=photos.readonly
&state=xyz789 HTTP/1.1
Host: auth.example.com
# 2. After the user approves, the browser is redirected back with a code
HTTP/1.1 302 Found
Location: https://photoapp.example.com/callback?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz789
# 3. The client exchanges the code for an access token (server-to-server)
POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https://photoapp.example.com/callback
&client_id=photo_app_123
&client_secret=SECRET_VALUE
# 4. Authorization server responds with tokens
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token": "eyJhbGciOi...",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"scope": "photos.readonly"
}Access Tokens, Scopes, and Expiration
The core artifact OAuth issues is the access token — an opaque or JWT-formatted string the client presents to a resource server, usually in an Authorization: Bearer <token> header. Each token is minted with one or more scopes, such as repo:read or photos.readonly, which the authorization server records and the resource server enforces; the resource server rejects any request for data outside the token's granted scopes, even if the token itself is otherwise valid and unexpired.
Cricket analogy: A Bearer token with scope highlights:read is like a broadcaster's pass stamped 'Boundary Camera Access Only' — valid for the whole match, but the security guard at the dressing-room door still turns you away because that scope isn't printed on your pass.
Access tokens are deliberately short-lived, often expiring in 15 minutes to an hour, to limit the damage if one leaks. To avoid forcing the user to re-authenticate constantly, the authorization server also issues a longer-lived refresh token that the client stores securely and exchanges for a fresh access token when the old one expires — without the user seeing a login screen again. If a refresh token is compromised, the authorization server can revoke it, immediately cutting off future access token renewals.
Cricket analogy: Like a day-pass to a stadium that expires at stumps each day, but a season-ticket holder has a renewable membership card that reissues a fresh day-pass every morning without queuing at the box office again.
OAuth 2.0 itself only defines authorization — proving what an app is allowed to do. It says nothing about verifying who the human user is; that's what OpenID Connect, a layer built on top of OAuth 2.0, adds via the ID token.
OAuth 2.0 vs OAuth 1.0a
OAuth 1.0a, published in 2010, required clients to cryptographically sign every request using HMAC-SHA1 and a shared secret, which made client implementation notoriously fiddly and error-prone. OAuth 2.0 dropped mandatory request signing in favor of relying on TLS (HTTPS) to protect tokens in transit, which simplified client libraries dramatically but shifted the security burden onto always using HTTPS and short-lived tokens. This tradeoff is why OAuth 2.0 is not backward-compatible with OAuth 1.0a — they are different protocols that happen to share a name.
Cricket analogy: Like the switch from manually verifying a scorer's handwritten signature on every over's scorecard to trusting the stadium's secure digital scoring feed over an encrypted line — faster, but only safe if the connection itself is genuinely secure.
OAuth 2.0 provides no security at all if used over plain HTTP — tokens sent unencrypted can be captured by anyone on the network. Always use HTTPS, and for public clients (mobile apps, SPAs), always use PKCE (RFC 7636) since they can't safely store a client secret.
- OAuth 2.0 (RFC 6749) is an authorization framework, not a login mechanism — it grants scoped, delegated access to resources.
- Clients receive access tokens, typically sent as
Authorization: Bearer <token>headers, instead of the user's password. - Scopes limit exactly what an access token can do, and the resource server enforces those limits server-side.
- Access tokens are short-lived; refresh tokens let clients get new access tokens without repeated user logins.
- OAuth 2.0 replaced OAuth 1.0a's mandatory request signing with reliance on TLS, simplifying clients but requiring HTTPS everywhere.
- OAuth 2.0 alone doesn't verify user identity — that's the job of OpenID Connect, built on top of it.
Practice what you learned
1. What problem does OAuth 2.0 primarily solve?
2. What header does a client typically use to send an OAuth access token to a resource server?
3. Why are OAuth 2.0 access tokens typically short-lived?
4. What is the main architectural difference between OAuth 1.0a and OAuth 2.0?
5. Which of the following does OAuth 2.0 by itself NOT provide?
Was this page helpful?
You May Also Like
OAuth 2.0 Roles and Terminology
A guided tour of the four OAuth 2.0 roles — resource owner, client, authorization server, resource server — and the core vocabulary you'll see in every spec and SDK.
OAuth vs Authentication
Clears up the most common OAuth misconception: OAuth 2.0 is an authorization protocol, not an authentication protocol, and explains where OpenID Connect fits in.
The Authorization Code Flow
A step-by-step walkthrough of OAuth 2.0's most widely used grant type, the authorization code flow, including why PKCE is now required for public clients.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics