OAuth / OAuth2

OAuth2 (Open Authorization) is the industry-standard protocol for delegated authorization — it lets a user grant a third-party application access to their data on another service, without handing over their password. Before OAuth, apps like Yelp would ask users to type their Google credentials directly into Yelp's site so Yelp could scrape their contacts; OAuth2 eliminated that pattern.

Authentication vs. Authorization

Authentication (AuthN) answers "who are you?" It verifies identity. Authorization (AuthZ) answers "what are you allowed to do?" It grants permissions. OAuth2 is strictly an authorization protocol; it issues access tokens, not identities (OIDC, covered in the SSO article, layers identity on top of it).

Authorization Code Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

OAuth2 defines four actors. The Resource Owner is the user who owns the data. The Client is your application that wants access to it. The Authorization Server is the identity provider (Spotify, Google, GitHub) that authenticates the user and issues tokens. The Resource Server holds the actual data. The key insight: the user's password never touches your application — they authenticate directly with the Authorization Server (Spotify). Your app only receives a limited access token for the specific scope the user approved (playlist-read, not playlist-delete). This is the "valet key" model — you get access to the car, not the house keys.

1 / 10.5×1×2×3×Playground

OAuth2 actors — Resource Owner, Client, Authorization Server, Resource Server

The most common OAuth2 scenario: you are building a web app (the Client) that wants to import a user's Spotify playlists.

Resource Owner: the user. Client: your web app. Authorization Server: Spotify's login system. Resource Server: Spotify's API holding the playlist data.

Step 1 — Request: The user clicks "Import Spotify Playlists." Your app redirects the browser to Spotify's Authorization Server, including your app's client ID and the requested Scope (e.g., playlist-read) in the URL.

Step 2 — Consent: Spotify prompts the user to log in, then displays a consent screen: "This app wants to read your playlists. Allow?" The user approves. Critically, the user's password was typed into Spotify — not into your app.

Step 3 — Authorization Code: Spotify redirects the browser back to your app with a temporary, one-time-use authorization code appended to the URL.

Step 4 — Token Exchange (Back-Channel): Your server takes that code and — hidden from the browser — sends it to Spotify's Authorization Server along with your app's client secret. Spotify validates both and returns an Access Token.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

The Authorization Code Flow uses a two-step exchange to keep the access token out of the browser. After the user approves, Spotify redirects back with a short-lived code in the URL (not the token — the URL is visible to browser extensions and the browser history). Your app server receives this code, then makes a server-to-server call to Spotify with the code plus your client secret. Only then does Spotify issue the actual access token — directly to your server, never visible in the browser. This back-channel exchange is why Authorization Code Flow is safe for web apps. The access token typically expires in 15-60 minutes; the longer-lived refresh token is used to silently request new access tokens without bothering the user.

1 / 10.5×1×2×3×Playground

Back-channel token exchange — authorization code swapped for access token server-to-server

Step 5 — Access Granted: Your app attaches the Access Token to the Authorization header of requests to Spotify's API. Spotify validates the token and returns the playlist data.

Why use an Authorization Code?

Why didn't Spotify return the Access Token directly in Step 3? The browser is exposed — extensions or injected scripts can read URL parameters. Returning a short-lived, single-use code instead means the actual token is only ever exchanged server-to-server in Step 4, out of reach of client-side attacks.

Scopes and Lifespans

OAuth2 tokens are deliberately constrained. A token is bound to the scopes the user approved: a token issued with playlist-read scope will be rejected if the client attempts to delete a playlist. Access tokens are short-lived — typically 15 to 60 minutes — so a stolen token has a narrow window of usefulness. Apps maintain continuous access by using a longer-lived Refresh Token to silently obtain new access tokens in the background without re-prompting the user.

Summary

OAuth2 is the industry standard for delegated authorization. It lets third-party apps access specific resources on a user's behalf without ever seeing the user's password. The Authorization Code Flow keeps tokens off the browser by exchanging them server-to-server. Scopes constrain what a token can do, and refresh tokens allow sustained access while keeping individual access tokens short-lived.