OAuth 2.0

OAuth 2.0 is the standard protocol for delegated authorization — letting a third-party application access resources you control on another service without handing over your password. “Sign in with Google,” “Connect your GitHub account,” “Grant Zapier access to your Gmail” all use OAuth.

The four roles: resource owner (the user), client (the third-party app), authorization server (the OAuth-issuing service, e.g., accounts.google.com), resource server (the API the client wants to call, e.g., gmail.googleapis.com).

The most common flow (authorization code with PKCE):

1. Client redirects user to the auth server.
2. User logs in and approves the requested scopes.
3. Auth server redirects back with a one-time authorization code.
4. Client exchanges the code (plus PKCE verifier) for an access token.
5. Client calls the resource server with the access token.

OAuth 2.0 is authorization-only. OpenID Connect (OIDC) is the authentication layer on top — it adds an ID token (a JWT with claims about who the user is) so the client can know who logged in, not just “some authorized user.” Most modern “Sign in with X” flows are OIDC, not pure OAuth.

Why PKCE is now mandatory for public clients: the original OAuth 2.0 authorization-code flow assumed the client could keep a secret. Mobile apps and single-page apps can’t — anyone can disassemble the app and extract the embedded secret. PKCE (Proof Key for Code Exchange, RFC 7636) replaces the static client secret with a per-flow random verifier hashed via SHA-256: the client sends the hash up front and reveals the plaintext only when exchanging the code, proving it’s the same client that initiated the flow. PKCE is now required for all public clients (OAuth 2.1, RFC 9700 BCP) and recommended for confidential clients too as defence-in-depth.

The four flows you should know and the two you should avoid: use Authorization Code + PKCE for almost everything (web, mobile, SPA). Use Client Credentials for machine-to-machine API calls where no user is present. The Implicit flow (returns access tokens directly in URL fragments) and Resource Owner Password Credentials flow (the client collects the password directly) are both deprecated in OAuth 2.1 — neither protects against modern attacks adequately. Any new OAuth integration should reject these even if a vendor offers them. Related: JWT, SAML. Reference: RFC 6749 — OAuth 2.0, RFC 7636 — PKCE.

Worked example

A “Connect Slack” button in your SaaS triggers a redirect to https://slack.com/oauth/v2/authorize?client_id=...&scope=chat:write,channels:read&redirect_uri=https://app.example.com/oauth/callback&state=xyz&code_challenge=BASE64URL(SHA256(verifier))&code_challenge_method=S256. The user approves; Slack redirects to https://app.example.com/oauth/callback?code=ONE_TIME_CODE&state=xyz. Your backend POSTs to https://slack.com/api/oauth.v2.access with the code, the original PKCE verifier, and the client ID. Slack returns {"access_token": "xoxb-...", "scope": "chat:write,channels:read", "team": {"id": "T123"}}. You store the access token server-side (never in browser local storage) and use it as Authorization: Bearer xoxb-... on subsequent Slack API calls. The whole exchange takes a few hundred milliseconds; the user sees one consent screen and never types a Slack password into your app.

When and why it matters

OAuth misconfigurations are one of the most-exploited categories in modern web security. Common failure modes: not validating the state parameter (enables CSRF on the callback), allowing wildcards in redirect_uri registration (enables token theft via open-redirect), storing access tokens in browser-accessible storage (XSS exfiltration), and treating refresh tokens as long-lived bearer tokens rather than rotating them on use. The OAuth 2.0 Security Best Current Practice (RFC 9700, published 2025) codifies the modern defaults: PKCE everywhere, exact-match redirect URIs, sender-constrained tokens (DPoP or mTLS) for high-value APIs, and refresh-token rotation with reuse detection. Following these turns most OAuth pen-test findings into non-issues. Reference: RFC 9700 — OAuth 2.0 Security BCP.