What Is OAuth

OAuth is an authorization protocol. It lets one service access another's resources without ever seeing the user's password. It replaces trust with tokens, and secrets with scopes.

Why It Matters

Passwords are a catastrophe. Users reuse them. Services store them in hashes that leak. When Site A needs Site B's data, asking for the user's password is a betrayal — of the user, and of both services. OAuth ends that. It introduces a third object: the token. The token carries permission, not identity. It expires. It can be revoked. It can be scoped to a single action. This is not a convenience. It is a structural shift from shared secrets to delegated authority. It makes the web composable. One service builds on another without owning the user's credentials. That is the practical importance. The philosophical importance is deeper: OAuth enforces the principle of least privilege. You get exactly the access you asked for, no more. No implicit trust. No ambient authority. Every permission is explicit, bounded, and auditable. That is the foundation of any system that claims to be open.

How It Works

OAuth 2.0 has four roles: the Resource Owner (the user), the Client (the app requesting access), the Authorization Server (the token issuer), and the Resource Server (the API holding the data).

Step one: the Client asks the Resource Owner for authorization. It does this by redirecting the user's browser to the Authorization Server with a request that includes a client ID, a redirect URI, and a list of scopes. The client ID is public. It identifies the app. The scopes are the permissions: read:profile, write:posts, delete:account. Each scope is a string. The Authorization Server shows the user what the Client wants. The user approves or denies.

Step two: if the user approves, the Authorization Server redirects the browser back to the Client's redirect URI with an authorization code. This code is single-use, short-lived, and bound to the client ID and redirect URI that started the flow. It proves the user said yes, but it is not a token.

Step three: the Client sends the authorization code to the Authorization Server's token endpoint, along with its client secret. The client secret is private. It never travels in the browser. The Authorization Server validates the code, the secret, and the redirect URI. If all match, it returns an access token and a refresh token. The access token is a bearer token. Whoever holds it can use it. The refresh token is for obtaining new access tokens when the old one expires. The refresh token is typically longer-lived and must be stored securely.

Step four: the Client sends the access token to the Resource Server on every API request, usually in the Authorization: Bearer <token> header. The Resource Server validates the token — by signature if it is a JWT, or by introspection if it is opaque — and returns the requested resource. If the token is expired, the Client uses the refresh token to get a new one. If the token is revoked, the request fails.

The flow above is the Authorization Code grant, the most common and the most secure for server-side apps. Other grants exist: Implicit (deprecated, for SPAs without a backend), Client Credentials (machine-to-machine, no user), and Device Code (for TVs and hardware without browsers). Each solves a specific constraint. Each trades security for convenience. The Authorization Code grant with PKCE (Proof Key for Code Exchange) is the modern standard for mobile and SPA apps. It removes the need for a client secret by adding a code verifier: a random string hashed and sent in the initial request, then verified in the token exchange. This prevents authorization code interception attacks on mobile devices.

The Contract

The protocol is a set of HTTP endpoints and JSON payloads. The Authorization Endpoint is a GET request. Parameters: response_type=code, client_id, redirect_uri, scope, state. The state parameter is a random string used to prevent CSRF attacks. The client must verify it matches on the return.

The Token Endpoint is a POST request. Content-Type: application/x-www-form-urlencoded. Parameters: grant_type=authorization_code, code, redirect_uri, client_id, client_secret. Response: a JSON object with access_token, token_type (always Bearer), expires_in (seconds), refresh_token (optional), and scope (the granted scopes, which may be a subset of the requested scopes).

The Resource Endpoint is a standard API. The access token travels in the Authorization: Bearer <token> header. The Resource Server responds with 200 and the resource, or 401 if the token is missing or invalid, or 403 if the token is valid but lacks the required scope.

Tokens are opaque to the Client. The Client does not parse them. It presents them. The Resource Server decides what they mean. If the token is a JWT, it contains claims: sub (subject, the user ID), iss (issuer), aud (audience, the Resource Server), exp (expiration), iat (issued at), scope (the granted permissions). The Resource Server validates the signature against the Authorization Server's public key. It rejects tokens with bad signatures, expired exp, or mismatched aud.

Real Examples

GitHub OAuth Apps. A developer wants to build a CI dashboard that shows the user's repositories and recent commits. The dashboard redirects the user to github.com/login/oauth/authorize with client_id and scope=repo. The user approves. GitHub redirects back with a code. The dashboard exchanges the code for a token using client_id, client_secret, and the code. The token has repo scope. The dashboard calls api.github.com/user/repos with Authorization: Bearer <token>. GitHub returns the repositories. The dashboard never sees the user's GitHub password.

Google Sign-In. A third-party app wants to let users sign in with Google. It redirects to accounts.google.com/o/oauth2/v2/auth with scope=openid profile email. The user approves. Google returns an authorization code. The app exchanges it for an access token and an ID token. The ID token is a JWT containing the user's sub, email, name, and picture. The app validates the ID token's signature against Google's public keys and uses the claims to create or authenticate a local user account. The access token lets the app call Google APIs like Calendar or Drive if the user granted those scopes.

Slack Apps. A team installs a Slack app. The app requests scope=chat:write:bot,channels:read. The team admin approves. Slack returns an access token to the app's backend. The token is stored server-side. The app uses it to post messages to channels and read channel listings. If the admin revokes the app in Slack's settings, the token becomes invalid. The next API call returns 401. The app cannot post anymore. The admin never shared a password.

Stripe Connect. A marketplace wants to pay sellers. It redirects sellers to Stripe's OAuth flow with scope=read_write. The seller connects their Stripe account. Stripe returns an access token that represents the seller's account. The marketplace stores the token and uses it to create charges on the seller's behalf. The token is scoped to the seller's account. The marketplace cannot access other sellers' data. The seller can revoke access in their Stripe dashboard. The token dies. The marketplace loses access. No password was ever exchanged.

Apple Sign In. An iOS app wants to authenticate users without creating a password system. It uses the Authorization Code grant with PKCE. The app generates a code verifier (a random 128-character string) and a code challenge (SHA256 of the verifier, base64url-encoded). It sends the challenge to Apple's authorization endpoint. Apple redirects back with a code. The app sends the code plus the original verifier to Apple's token endpoint. Apple hashes the verifier and checks it against the challenge. If they match, Apple returns the tokens. The verifier never leaves the device. An attacker who intercepts the authorization code cannot exchange it without the verifier.

Common Mistakes

Developers store the client secret in mobile apps. The client secret is not secret on a device. Anyone can extract it. Mobile apps must use PKCE and omit the client secret entirely.

Developers send tokens in URLs. URLs end up in logs, browser history, and referrer headers. Tokens must travel in headers or POST bodies. Never in query strings.

Developers skip the state parameter. Without state, an attacker can craft a login link that redirects the user to the attacker's account after the OAuth flow. The app thinks the user is the attacker. This is a session fixation attack. Always validate state.

Developers request more scopes than they need. Each scope is a liability. If your app leaks, the attacker gets every scope you requested. Request the minimum. If you need more later, re-authorize.

Developers treat the access token as a session token. It is not. It is an authorization credential for a specific set of APIs. Session management is a separate concern. Do not put user identity in a session token and call it OAuth. Use an ID token for identity, an access token for authorization.

Developers build their own OAuth server. OAuth is a protocol, not a library. Implementing it correctly requires handling token rotation, revocation, scope validation, JWT signing, key rotation, and PKCE. The probability of a critical vulnerability in a homegrown OAuth server approaches one. Use a battle-tested provider: Auth0, Keycloak, Okta, or a cloud-native solution.

Developers ignore token expiration. An access token expires. The refresh token expires too, eventually. If you do not handle 401 responses by refreshing, your app breaks. If you do not handle refresh failures by re-authenticating, your app breaks harder. Build the full lifecycle.

Connection to OIP

OAuth is a protocol, not a product. It is defined by RFC 6749 and RFC 7636. Anyone can implement it. Anyone can audit it. That is openness. The token itself is a deterministic object. Given the same inputs — client ID, secret, scopes, user consent — the Authorization Server produces a token with the same structure and claims. The Resource Server's validation is deterministic too. Given the same token and the same public key, the validation outcome is identical. That is determinism. Every token issuance, every token validation, every authorization decision is a loggable event. The scopes are explicit. The permissions are bounded. The user can revoke. The admin can audit. That is auditability. OAuth is not a philosophy. It is a working protocol. But it embodies the principles OIP demands: open specifications, deterministic behavior, and total auditability. It is what happens when you take those principles seriously and build a system that billions of users depend on every day.

Connection to the Grain Philosophy

This protocol is part of the Open Inventory Protocol — a living system of self-describing voxels that serves the Grain philosophy. The OIP is the interface. The philosophy is the core.