What Is OAuth 2.0 and How Does It Work?
OAuth 2.0 is an authorization framework that lets an application access resources on a user's behalf without ever seeing their password. The user grants permission, an authorization server issues an access token, and the app uses that token to call APIs. It's what powers "Sign in with Google" and "Connect your account" buttons everywhere.
OAuth is widely used and widely misunderstood. Here's a clear walkthrough.
The Problem OAuth Solves
Before OAuth, letting App A use your data from Service B meant giving App A your B password — risky and impossible to scope or revoke. OAuth replaces that with delegated authorization: you grant a specific app limited access, without sharing credentials, and you can revoke it anytime.
The Four Roles
| Role | Who it is |
|---|---|
| Resource Owner | You — the user who owns the data |
| Client | The app requesting access |
| Authorization Server | Issues tokens after you consent (e.g., Google's auth server) |
| Resource Server | The API holding your data, which accepts the token |
How the OAuth Flow Works
The most common and secure flow is the Authorization Code flow:
- The app redirects you to the authorization server (e.g., Google's login).
- You authenticate and consent to the requested scopes ("allow read access to your profile").
- The auth server redirects back to the app with a short-lived authorization code.
- The app exchanges that code (plus its client secret) for an access token.
- The app calls the API, sending the access token in the
Authorization: Bearerheader.
GET /api/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6...
Public clients (mobile/SPA) add PKCE to secure the code exchange without a secret — generate the parameters with our PKCE Generator.
Access Tokens vs Refresh Tokens
- Access token — short-lived (minutes to an hour); sent with every API call. Often a JWT you can decode to inspect scopes and expiry.
- Refresh token — long-lived; used to obtain a new access token when the old one expires, without making you log in again.
Inspect a real token's claims with our OAuth Token Inspector.
Scopes: Limiting What an App Can Do
Scopes define exactly what access the token grants — read:profile, write:calendar, etc. The user sees these on the consent screen, and the resource server enforces them. This is what makes OAuth access least-privilege instead of all-or-nothing.
OAuth vs OpenID Connect (OIDC)
A crucial distinction:
- OAuth 2.0 is for authorization — what an app can access.
- OpenID Connect (OIDC) is an identity layer on top of OAuth for authentication — who you are. It adds an ID token (a JWT with user identity).
"Sign in with Google" is really OIDC. Debug an OIDC flow with our OIDC Debugger, and compare auth standards in SAML vs OAuth vs OIDC.
Frequently Asked Questions
What is OAuth 2.0? An authorization framework that lets apps access your data on your behalf using tokens, without ever receiving your password.
How does the OAuth flow work? You log in and consent at the authorization server, which returns a code; the app exchanges that code for an access token and uses it to call APIs.
What is the difference between OAuth and OpenID Connect? OAuth handles authorization (what an app can access). OIDC adds authentication (who you are) on top, issuing an ID token.
What is an access token vs a refresh token? An access token is short-lived and sent with API calls; a refresh token is long-lived and used to get new access tokens without re-login.
Is OAuth authentication or authorization? OAuth itself is authorization. Authentication ("who are you") is handled by OpenID Connect, which builds on OAuth.
Related Reading
Once you internalize "delegated access via scoped tokens," every OAuth login button makes sense — and so does the difference between proving what you can do (OAuth) and who you are (OIDC).