What is OAuth? — Open Authorization Framework Explained

Definition

OAuth 2.0 (Open Authorization) is an industry-standard authorization framework that enables applications to obtain limited access to user accounts on an HTTP service. Instead of sharing a user's password with a third-party application, OAuth allows the user to grant a token that provides scoped, temporary access to specific resources.

OAuth 2.0 is defined in RFC 6749 and is used by virtually every major API platform including Google, GitHub, Facebook, Twitter, Microsoft, and Stripe. It is the foundation of modern API authorization.

OAuth 2.0 Roles

OAuth defines four distinct roles that interact during the authorization process:

The OAuth Flow at a Glance

Resource Owner (User)
     │
     ▼
   Client (App) ─────────► Authorization Server
     │                           │
     │                           ├── Authenticates user
     │                           ├── Gets consent
     │                           └── Issues authorization code
     │
     ├── Exchanges code for token ──► Authorization Server
     │
     ├── Uses access token ─────────► Resource Server
     │                                    │
     │                                    └── Returns protected data
     ▼
   Successful API access

Grant Types

OAuth 2.0 defines several grant types — different flows for different application scenarios:

Authorization Code Grant (Recommended for Web Apps)

The most common and most secure flow. The client receives an authorization code after the user authenticates, then exchanges it for an access token on the server side:

1. User clicks "Sign in with Provider"
2. Browser redirects to the authorization server
3. User authenticates and grants consent
4. Authorization server redirects back with a code
5. Client server exchanges the code for an access token (using client secret)
6. Client uses the access token to call the resource server

Best for: Server-side web applications where the client secret can be stored securely.

Authorization Code with PKCE (Recommended for Mobile & SPAs)

PKCE (Proof Key for Code Exchange) extends the authorization code flow to prevent authorization code interception attacks. The client generates a cryptographic challenge before the redirect:

1. Client generates a code_verifier (random string) and code_challenge (SHA-256 hash of the verifier)
2. The challenge is sent with the authorization request
3. When exchanging the code, the client sends the original verifier
4. The authorization server verifies the challenge matches

Best for: Mobile apps, single-page applications (SPAs), and any client that cannot securely store a client secret.

Client Credentials Grant

The client authenticates itself (not on behalf of a user) to access resources:

1. Client sends its client_id and client_secret directly to the authorization server
2. Authorization server returns an access token
3. Client uses the token to call the resource server

Best for: Server-to-server communication, machine-to-machine (M2M) APIs, cron jobs, and backend services.

Implicit Grant (Deprecated)

The implicit grant was designed for browser-based apps and returned the access token directly in the URL fragment. It is now deprecated due to security concerns — the token is exposed in the browser history and vulnerable to interception. Use PKCE instead.

Access Tokens vs Refresh Tokens

Why Two Tokens?

• Security: Short-lived access tokens limit the damage if compromised
• UX: Refresh tokens allow the client to obtain new access tokens without bothering the user to re-authenticate
• Control: Servers can revoke refresh tokens without impacting active sessions

Scopes

Scopes define the specific permissions the client is requesting. They limit what the access token can do:

Scopes are requested by the client during authorization and displayed to the user for consent. The user can often choose to grant a subset of the requested scopes.

OAuth vs SAML vs OpenID Connect

When to Use What

• OAuth 2.0 — When you need to authorize third-party app access to user data (e.g., "Allow this app to post to my Twitter feed")
• OpenID Connect (OIDC) — When you need to authenticate users (e.g., "Sign in with Google"), OIDC extends OAuth 2.0 with an id_token (a JWT containing user identity)
• SAML 2.0 — In enterprise environments where XML-based SSO is standard (e.g., corporate Okta/ADFS integrations)

The Key Distinction

OAuth 2.0 is about what you can do (authorization). OpenID Connect is about who you are (authentication). They are often used together.

Common OAuth Flow (Authorization Code)

Step-by-Step Diagram

┌──────────┐          ┌──────────┐          ┌──────────┐
│   User   │          │  Client  │          │  Auth    │
│ (Browser)│          │  (App)   │          │  Server  │
└────┬─────┘          └────┬─────┘          └────┬─────┘
     │                     │                     │
     │ 1. Click "Login"    │                     │
     │────────────────────►│                     │
     │                     │                     │
     │ 2. Redirect to Auth │                     │
     │◄────────────────────│                     │
     │                     │                     │
     │ 3. Authenticate     │                     │
     │──────────────────────────────────────────►│
     │                     │                     │
     │ 4. Consent grant    │                     │
     │──────────────────────────────────────────►│
     │                     │                     │
     │ 5. Auth code redirect                     │
     │◄──────────────────────────────────────────│
     │                     │                     │
     │ 6. Code to server   │                     │
     │────────────────────►│                     │
     │                     │ 7. Exchange code    │
     │                     │    + client secret  │
     │                     │────────────────────►│
     │                     │                     │
     │                     │ 8. Access + refresh │
     │                     │◄────────────────────│
     │                     │                     │
     │                     │ 9. API call + token │
     │                     │────────────────────►│
     │                     │    (Resource Server)│
     │                     │                     │
     │ 10. Success data    │                     │
     │◄────────────────────│                     │
┌────┴─────┐          ┌────┴─────┐          ┌────┴─────┐
│   User   │          │  Client  │          │  Auth    │
│ (Browser)│          │  (App)   │          │  Server  │
└──────────┘          └──────────┘          └──────────┘

Common OAuth Implementation Mistakes

1. Storing access tokens in localStorage — vulnerable to XSS attacks. Use httpOnly cookies or secure in-memory storage.
2. Not validating the redirect_uri — allows attackers to intercept authorization codes.
3. Using implicit grant — deprecated for good reason; always use authorization code + PKCE for browser-based apps.
4. Not using state parameter — without a state parameter, your app is vulnerable to CSRF attacks on the redirect callback.
5. Exposing client_secret in client-side code — secrets in mobile or SPA code are not secrets; use PKCE instead.
6. Ignoring token expiry — always check expiration before using an access token.
7. Missing scope validation — validate that the token has the required scopes before granting access.

LangStop API & Security Tools

• JWT Encoder — Create and sign JWTs for OAuth tokens
• JWT Decoder — Inspect OAuth access tokens
• REST API Client — Test OAuth-protected API endpoints
• API Tools — Collection of API debugging utilities
• URL Encoder — Encode OAuth callback URLs and parameters