What Is OAuth 2.0?
Every time you click "Allow this app to access your Google Contacts" without ever typing your Google password into that app, OAuth 2.0 is the standard quietly making it possible. This guide explains exactly what it is and how it works, from zero assumptions.
Imagine you’re staying at a hotel and want housekeeping to be able to enter your room to clean it while you’re out — but you don’t want to hand over your actual room key, since that key also opens the minibar, the safe, and lets someone stay overnight. Instead, the front desk issues a limited-access keycard that only unlocks the door, works only between 10am and 2pm, and expires the day you check out. OAuth 2.0 solves exactly this kind of problem for apps and websites: it lets you grant one application limited, revocable access to your data on another service — without ever handing over your actual password. This guide unpacks that idea piece by piece.
1What Is OAuth 2.0?
The foundation every later chapter builds on.
OAuth 2.0 is an open standard for delegated authorization — a set of agreed-upon rules that let one application access specific data or perform specific actions on your behalf on another service, without ever seeing your password for that service. The name is short for “Open Authorization,” and it was designed specifically to solve a problem that used to be common: apps asking users to type their password from a completely different service directly into them.
Think back to the hotel keycard example. You (the guest) are the one who owns access to the room. The front desk (the service that owns your data) issues a limited keycard (a token) to housekeeping (the app requesting access) — a keycard that only opens what it needs to, for only as long as it needs to. Housekeeping never learns your actual master key combination; they just carry a scoped, revocable credential you approved.
OAuth 2.0 exists because, before it became standard, users routinely typed their email password directly into unrelated third-party apps just so those apps could, say, read their contact list — a practice that was both insecure and impossible to control precisely.
Delegated Access
One app gets permission to act on your behalf, without impersonating you entirely.
No Password Sharing
The requesting app never sees or stores your actual password for the other service.
Scoped Permission
Access can be limited to specific data or actions, rather than granting everything.
Revocable
Access can be withdrawn later without changing your actual account password.
OAuth 2.0 is fundamentally about authorization — what an app is allowed to do — not about proving who a human user is. That distinction is important enough to get its own chapter next.
2OAuth 2.0 vs. Authentication vs. OpenID Connect
One of the most persistent points of confusion in this entire field.
OAuth 2.0 is very frequently mislabeled as a “login” system, but strictly speaking, it was designed to answer a different question than authentication does.
Authentication asks “who are you?” — like showing your ID at a building’s front desk. OAuth asks a different question entirely: “what is this specific visitor allowed to do inside the building?” — like handing a contractor a keycard that only opens the server room, without that keycard proving anything about the contractor’s actual identity on its own.
Where OpenID Connect Fits In
Because “sign in with Google” style buttons clearly needed both identity verification and permission-granting, an extra layer called OpenID Connect (OIDC) was built directly on top of OAuth 2.0. OIDC adds a standardized way to also prove identity — producing a special ID Token alongside OAuth’s usual access token — turning the combination into a full login system, not just a permissions system.
| Standard | Primary Question It Answers | Typical Output |
|---|---|---|
| Authentication (general concept) | Who are you? | Confirmed identity |
| OAuth 2.0 | What is this app allowed to do? | An access token |
| OpenID Connect | Who is this user, and what can this app do? | An ID token plus an access token |
Successfully completing an OAuth flow proves an app was granted access — it does not, by itself, reliably prove the identity of the person who granted it. This is precisely the gap OpenID Connect was created to close.
3The Four Roles in Every OAuth Flow
Every OAuth interaction, no matter how complex, involves exactly these four participants.
Resource Owner
You — the person who owns the data and has the authority to grant or deny access to it.
Client
The application requesting access to your data — for example, a photo-printing app wanting your cloud photos.
Authorization Server
The system that verifies you, asks for your consent, and issues the access token — for example, Google’s own servers.
Resource Server
The system actually holding your data, which checks the access token before releasing anything — for example, the Google Photos API.
Back to the hotel: you are the resource owner, the cleaning company is the client requesting access, the front desk issuing the keycard is the authorization server, and your actual hotel room — the thing being accessed — is the resource server.
The authorization server and resource server are sometimes the exact same system (like Google handling both), and sometimes entirely separate systems — but the four distinct roles remain conceptually separate either way.
4How OAuth Works Internally: The Authorization Code Flow
The most common and most secure OAuth flow, used by the vast majority of modern web and mobile apps.
The Client Redirects You to the Authorization Server
The requesting app sends your browser to the service that owns your data, listing exactly what access it’s asking for.
You Log In and Review the Consent Screen
You authenticate with the service (if you haven’t already) and see a clear screen listing exactly what the app wants to access.
You Approve or Deny the Request
Clicking “Allow” tells the authorization server you consent to the specific access being requested — nothing more.
A Short-Lived Authorization Code Is Sent Back
The authorization server redirects you back to the app carrying a temporary, single-use code — not the actual access token yet.
The App Exchanges the Code for an Access Token
Privately, server-to-server, the app trades that code for a real access token it can use to call the resource server.
sequenceDiagram
participant U as User (Resource Owner)
participant App as Client Application
participant AS as Authorization Server
participant RS as Resource Server
App->>U: Redirect to Authorization Server
U->>AS: Log in and review consent screen
U->>AS: Approve requested access
AS-->>App: Redirect back with short-lived code
App->>AS: Exchange code for access token (server-to-server)
AS-->>App: Return access token
App->>RS: Call API using access token
RS-->>App: Return requested data
Notice that your password never leaves the authorization server’s own login page, and the code your browser carries is useless on its own — it must be exchanged for a token through a private, server-to-server step the browser never sees.
5Common OAuth Grant Types
The Authorization Code flow isn’t the only pattern — OAuth defines several “grant types” for different situations.
Authorization Code
The standard flow for web and mobile apps with a user present, described in Chapter 4.
Authorization Code with PKCE
An enhanced version of the standard flow, adding extra protection for apps that can’t safely keep a secret, like mobile and single-page apps.
Client Credentials
Used when there’s no human user at all — one backend service authenticating directly to another as itself.
Device Code
Designed for devices without a convenient keyboard or browser — like a smart TV — showing a short code to enter on a separate phone or computer.
Refresh Token Grant
Used to obtain a fresh access token once the current one expires, without asking the user to log in all over again.
Client Credentials in Practice
A nightly batch job that syncs data between two internal company systems has no human user actively clicking “Allow” — it authenticates as itself, using the Client Credentials grant, to prove it’s an approved service before pulling data.
Device Code Flow in Practice
Signing into a streaming app on a smart TV by typing a short code on your phone, instead of typing your full password using a TV remote, is a real-world use of the Device Code grant.
An older pattern called the Implicit Grant, which returned tokens directly in the browser’s address bar without an exchange step, is now considered outdated and insecure — modern guidance recommends Authorization Code with PKCE instead, covered further in Chapter 9.
6Scopes and Consent
How OAuth keeps access precisely limited to what was actually agreed to.
A scope is a specific, named permission an app can request — such as “read your calendar” or “post on your behalf.” Rather than granting all-or-nothing access to an entire account, OAuth lets the requesting app list exactly which scopes it needs, and the consent screen shows the user precisely what’s being requested before they approve anything.
flowchart TD
A[App Requests Specific Scopes] --> B[Authorization Server Shows Consent Screen]
B --> C{User Reviews Requested Scopes}
C -->|Approves| D[Token Issued, Limited to Approved Scopes]
C -->|Denies| E[Access Refused, No Token Issued]
D --> F[Resource Server Checks Token's Scopes on Every Request]
Scopes are like the specific boxes you tick on a form authorizing a courier to collect a package — “may collect from the lobby,” “may not enter the apartment,” “may not accept other deliveries on my behalf.” The courier’s authority is precisely bounded by exactly what was ticked, nothing assumed beyond it.
The resource server checks the token’s scopes on every single request, not just at login — so even a valid, unexpired token can’t be used to access data outside what was originally approved.
7Tokens in OAuth: Access Tokens vs. Refresh Tokens
The two key pieces of “proof” that come out of a successful OAuth flow.
| Token Type | Purpose | Typical Lifespan |
|---|---|---|
| Access Token | Presented on every API call to prove the app has permission | Short — often minutes to a couple of hours |
| Refresh Token | Used to obtain a brand-new access token once the old one expires | Long — often days, weeks, or until revoked |
| ID Token (OpenID Connect only) | Proves the identity of the human user who logged in | Short, generally used once right after login |
An access token is like a same-day event wristband — quick to check, but it expires that evening. A refresh token is more like the original ticket stub kept safely at home, which can be exchanged at the box office for a fresh wristband tomorrow, without having to buy an entirely new ticket.
Keeping access tokens short-lived limits the damage window if one is ever stolen, while the more sensitive, longer-lived refresh token is generally kept more carefully guarded, often only on a secure backend rather than directly in a browser.
8Security Protections Built Into OAuth
OAuth’s design includes several specific defenses against realistic attacks.
Redirect URI Validation
The authorization server only sends codes and tokens back to a pre-registered, trusted application address, blocking attempts to redirect them elsewhere.
State Parameter
A unique, unpredictable value the app generates and checks on return, defending against attackers tricking a user into completing someone else’s OAuth flow.
PKCE (Proof Key for Code Exchange)
An extra secret generated fresh for each login attempt, ensuring only the same app that started the flow can complete the code exchange.
Short-Lived, Single-Use Codes
Authorization codes expire quickly and can only be exchanged once, so even an intercepted code is useless soon after.
Apps that run entirely on a user’s device — like a mobile app or a browser-based app — can’t safely keep a permanent secret the way a server-based backend can, so PKCE gives them an equivalent protection generated fresh on each login attempt instead.
9Design Patterns and Anti-Patterns
Lessons the industry learned from real OAuth implementation mistakes.
Problem
Using the older Implicit Grant, which returns the access token directly in the browser’s visible address bar, with no exchange step.
Why It’s Harmful
Tokens exposed directly in a URL can end up logged in browser history, server access logs, or leaked through the “referrer” of a linked page, giving attackers more opportunities to capture them.
Correct Approach
Use the Authorization Code flow with PKCE instead, which keeps the actual access token out of the browser’s visible address entirely, exchanging it only through a private step.
Problem
Requesting overly broad scopes “just in case” the app might need them later, rather than only what’s actually needed right now.
Why It’s Harmful
Broad scopes increase what an attacker could do if the app or its stored tokens were ever compromised, and they make users understandably wary when a consent screen asks for far more access than the app’s purpose seems to justify.
Correct Approach
Request only the minimum scopes genuinely needed for the current feature, and request additional scopes later, in context, only when a new feature actually requires them.
Design Pattern: Short-Lived Access, Long-Lived Refresh
Pairing a short-lived access token with a carefully guarded, longer-lived refresh token balances convenience (not logging in constantly) against risk (limiting how long a stolen access token stays useful).
10Best Practices and Common Mistakes
Practical guidance for anyone integrating with or evaluating an OAuth-protected service.
Always Prefer Authorization Code With PKCE
This is the currently recommended flow for essentially all modern web, mobile, and single-page applications.
Request the Narrowest Scopes Possible
Ask only for what’s genuinely needed right now, reducing both risk and how alarming the consent screen looks to users.
Store Refresh Tokens Securely
Because they’re long-lived and powerful, refresh tokens deserve the strongest storage protection available on the platform in use.
Let Users See and Revoke Granted Access
Give users an easy way to review which apps have access to their account and remove that access at any time.
Common missteps include confusing OAuth with a full login system without adding OpenID Connect, skipping the state parameter, hardcoding overly broad redirect URI patterns, and forgetting that an expired refresh token means the user must log in again from scratch.
11Advantages and Disadvantages of OAuth 2.0
A fair look at what OAuth gains you — and what it costs.
Advantages
- Users never hand their actual password to a third-party app
- Access can be precisely scoped rather than all-or-nothing
- Access can be revoked at any time without changing the account password
- Widely adopted standard, supported by virtually every major platform
Disadvantages / Trade-offs
- More complex to implement correctly than a simple password check
- Several grant types and options can be confusing for newcomers to choose between
- Misconfiguration (like overly broad redirect URIs) can introduce real vulnerabilities
- By itself, doesn’t prove user identity without the added OpenID Connect layer
12Monitoring and Auditing OAuth Activity
Because tokens represent standing access, watching how they’re issued and used matters.
Token Issuance Logging
Recording when and to which app an access or refresh token was issued makes it possible to trace exactly what access exists at any given time.
Scope Auditing
Periodically reviewing which apps hold which scopes helps catch cases where access has grown broader than actually needed.
Unusual Token Usage Alerts
Flagging access tokens suddenly used from a very different location or pattern than usual can catch a stolen token in active use.
User-Facing Access Reviews
Giving end users a clear list of connected apps and the ability to revoke any of them builds trust and limits long-forgotten, unused access.
13Real-World and Industry Examples
Seeing OAuth 2.0 in action across services you likely already use.
“Sign In With Google/Facebook/Apple” Buttons
These rely on OAuth 2.0 combined with OpenID Connect, letting a website confirm your identity and request limited profile access without ever seeing your actual account password.
Connecting a Calendar App to Your Email Account
When a scheduling tool asks to “view your calendar events,” it’s requesting a narrowly scoped OAuth grant — access to calendar data specifically, not your entire email inbox.
Team Chat App Integrations
Installing a bot or integration into a workplace chat tool typically triggers an OAuth consent screen listing exactly what channels or data the integration is requesting access to.
Developer API Access Tokens
Code hosting and cloud platforms commonly use OAuth’s Client Credentials grant to let automated tools and scripts authenticate as a service account, without a human logging in interactively each time.
14Frequently Asked Questions
Not by itself. OAuth 2.0 is fundamentally about granting limited access, not proving identity. Login functionality is typically added on top through OpenID Connect, which layers identity verification onto OAuth’s authorization mechanism.
No — under the standard Authorization Code flow, your password is only ever typed into the authorization server’s own login page, never into the requesting app itself.
A scope is a specific, named permission — like “read your calendar” — that an app requests. It lets access be precisely limited rather than granting everything on your account at once.
Short expiry limits how long a stolen or leaked access token remains useful to an attacker, while a separate, more carefully guarded refresh token allows a fresh access token to be obtained without asking the user to log in again.
Yes — most services provide a settings page listing every app you’ve granted access to, letting you revoke that access at any time without needing to change your account password.
PKCE (Proof Key for Code Exchange) is an added protection that generates a unique secret for each login attempt, ensuring that only the exact app that started the OAuth flow can complete it — an important safeguard for mobile and browser-based apps that can’t securely store a permanent secret.
15Summary and Key Takeaways
OAuth 2.0 is the standard that made “let this app access some of my data, without giving it my password” a safe, precise, and revocable action, rather than a risky one. By separating who owns the data, who’s requesting access, who verifies identity, and who actually holds the data into four distinct roles — and by exchanging short-lived codes for scoped, expiring tokens rather than passing passwords around — OAuth quietly powers an enormous share of the connections between today’s apps and services.
Key Takeaways
- OAuth 2.0 is about delegated authorization — granting limited access, not proving identity on its own.
- Every flow involves four roles: the resource owner, the client, the authorization server, and the resource server.
- The Authorization Code flow keeps passwords isolated, exchanging a short-lived code for a token through a private, server-to-server step.
- Scopes precisely limit what an app can access, and are shown clearly to the user on a consent screen before anything is granted.
- Access tokens are short-lived by design, while refresh tokens are longer-lived and require stronger protection.
- PKCE and the state parameter add critical protection for mobile and browser-based apps that can’t safely hold a permanent secret.
- OpenID Connect extends OAuth into a full login system by adding a standardized way to also verify user identity.