OAuth 2.0

OAuth 2.0 is a delegation protocol. The cast:

• Resource Owner (User): the person who owns the data.
• Client (App): the third-party app that wants to access the data.
• Authorization Server: issues tokens after the user consents.
• Resource Server: hosts the data; accepts tokens.

The flow: the client asks the user for permission. The user authenticates with the authorization server (Google, GitHub) and consents to the scopes requested. The authorization server gives the client an access token. The client uses the token to call the resource server's API. The user's password is never shared with the client.

OAuth is authorization, not authentication — it grants access, it doesn't prove identity. (OpenID Connect, built on OAuth, adds authentication.)

Different clients need different flows:

• Authorization Code (with PKCE): the standard for web apps, SPAs, and mobile apps. The user logs in via the provider, the app gets a code, exchanges it for a token. PKCE (Proof Key for Code Exchange) replaces the client secret with a dynamic challenge — essential for clients that can't keep a secret (SPAs, mobile).
• Client Credentials: for service-to-service access with no user. The service authenticates with its own credentials and gets a token. Used by backend integrations, scheduled jobs.
• Device Code: for devices without a browser (smart TVs, IoT). The device shows a code; the user goes to a URL on their phone and enters it.
• Resource Owner Password Credentials: deprecated. The client takes the user's password directly. Only used for legacy migrations; removes OAuth's main security benefit.

Implicit flow (formerly used for SPAs) is deprecated — use Authorization Code + PKCE instead. It returned the token directly in the URL fragment, which exposed it to attackers via referrer and other channels.

OAuth tokens:

• Access token: short-lived (5 min – 1 hour), used to call the API. Sent in the Authorization: Bearer ... header.
• Refresh token: long-lived (days – weeks), used to get new access tokens without re-prompting the user. Stored server-side; never sent to the browser in SPAs.
• Scopes: permissions attached to the token. read:user, write:repo, etc. The resource server checks scopes on every request.

Access tokens can be opaque (a random string the server looks up) or JWTs (self-contained, signed). Opaque tokens allow easy revocation; JWTs are stateless. The trend is JWT access tokens + opaque refresh tokens.

The principle of least privilege applies: clients should request only the scopes they need. The user sees the scopes during consent and can decline. An app requesting repo (full read/write to all repos) when it only needs read:user is suspicious — and users should decline.

OAuth security pitfalls:

• Redirect URI validation: the redirect_uri must be an exact match against registered URIs. Wildcard matching lets an attacker redirect the code to their own server.
• State parameter: prevents CSRF. Without it, an attacker can inject their own authorization code into the user's session, linking the attacker's account to the user's session.
• Token storage: don't store access tokens in localStorage (XSS-vulnerable). For SPAs, use HttpOnly cookies set by the backend, or in-memory storage with refresh-on-reload.
• PKCE for public clients: SPAs and mobile apps can't keep a client secret. PKCE replaces it with a dynamic challenge, preventing code interception.
• Scope validation: the resource server must validate scopes on every request. Skipping it lets a token with read scope call write endpoints.

The lesson: don't roll your own OAuth integration. Use a well-tested library (NextAuth, Passport, Auth0). The protocol has many footguns; the libraries handle them.

Mental model. Think of OAuth 2.0 as a deliberate boundary in a system. The boundary exists because something becomes harder to manage when everything is done in one place: latency, scale, failure isolation, consistency, cost, or team ownership. The useful question is not “what does OAuth 2.0 mean?” but “what pressure makes this boundary worth introducing, and what new failure mode does it create?”

Numerical lens: write down traffic, payload size, read/write ratio, peak multiplier and durability target before choosing a component. The numbers should justify the architecture.

Answer this without notes: When would you choose OAuth 2.0, and when would you intentionally avoid it? Mention at least one bottleneck it addresses, one failure mode it introduces, and one alternative. Then quantify the workload you are designing for.

Numerical sanity check

A practical blast-radius question: if one credential is compromised, how many users, services, records or regions could it affect? Prefer designs where that number is deliberately bounded.