OAuth 2.0 and OpenID Connect Explained

OAuth 2.0 defines four roles. The Resource Owner is the user. The Client is the app requesting access — a mobile app, a web app, a CLI tool. The Authorization Server authenticates the Resource Owner and issues tokens. The Resource Server is the API that accepts those tokens and serves data. OAuth's entire job is letting the Client call the Resource Server on the Resource Owner's behalf, with the Resource Owner's explicit consent, without the Client ever seeing the Resource Owner's password.

Notice what's missing from that list: nothing in OAuth 2.0 itself tells the Client who the Resource Owner is. The access token OAuth produces is scoped to calling the Resource Server's API — it was never designed to prove identity back to the Client that requested it. Early "social login" implementations that just checked whether a token could fetch a profile endpoint were repurposing an authorization protocol as an authentication one, which is exactly the gap OpenID Connect closes.

This is the flow behind almost every "Sign in with..." button today, for web apps, mobile apps, and single-page apps alike. The Client first generates a random code_verifier and derives a code_challenge from it (a SHA-256 hash, base64url-encoded). It redirects the Resource Owner to the Authorization Server's /authorize endpoint with response_type=code, its client_id, a redirect_uri, requested scope, a state value, and that code_challenge.

The Resource Owner authenticates and consents at the Authorization Server — the Client never sees their password. The Authorization Server redirects back to redirect_uri with a short-lived authorization code and the original state (which the Client checks matches, to prevent CSRF against this callback). The Client then exchanges that code, plus the original code_verifier, at the token endpoint. The Authorization Server hashes the code_verifier it just received and confirms it matches the code_challenge from the first request — only then does it issue tokens. PKCE (Proof Key for Code Exchange) is this challenge/verifier pair, and it is what stops anyone who intercepts the authorization code alone from redeeming it: without the original code_verifier, the intercepted code is useless.

OpenID Connect adds one crucial thing on top of OAuth 2.0: the ID token, a signed JWT the Authorization Server (now acting as an "OpenID Provider") issues alongside the access token when the Client requests the openid scope. The ID token carries standardized claims — sub (a stable subject identifier for the user), iss (which provider issued it), aud (which client it was issued for), exp/iat — and it is specifically meant for the Client to establish who just logged in, unlike the access token, which is meant for calling the Resource Server.

The fix for the OAuth-as-login mistake is exactly this: validate the ID token's signature against the provider's published keys, and check that its aud claim equals your own client_id. That aud check is what closes the historical vulnerability class where a token issued to a different client (for some unrelated API scope) gets replayed against your app as if it were a login — an access token alone carries no equivalent audience guarantee your Client can rely on.

Not every OAuth exchange involves a Resource Owner. The Client Credentials flow is machine-to-machine: a backend service authenticates directly to the Authorization Server with its own client_id and client_secret (or a signed JWT assertion) and receives an access token scoped to itself, not to any user — the right shape for a scheduled job or service calling another service's API with no human in the loop.

Two older flows are now discouraged. The Implicit flow returned the access token directly in the URL fragment with no code-exchange step and no refresh token — convenient for early single-page apps, but it exposes tokens to browser history, referrer leakage, and any script on the page; PKCE-secured Authorization Code has fully replaced it. The Resource Owner Password Credentials flow had the Client collect the user's username and password directly and trade them for a token — which defeats OAuth's core purpose of never letting the Client see the password, and should only ever appear in a legacy migration path, never a new integration.

Trigger. A mobile app registers a custom URL scheme (myapp://callback) as its OAuth redirect URI. A second, malicious app on the same device registers the same custom URL scheme — the operating system has no way to guarantee uniqueness the way a verified HTTPS domain does. Symptom. When the Authorization Server redirects back with the authorization code, the OS delivers it to whichever app handles that scheme, sometimes the malicious one instead of the legitimate app.

Root mechanism. Without PKCE, an authorization code alone is enough to redeem tokens at the /token endpoint — whoever intercepts the code can trade it in, no additional secret required. Recovery: because the legitimate app generated and privately held the code_verifier, the malicious app's attempt to redeem the intercepted code fails the Authorization Server's hash check — it has the code, but not the verifier that code was bound to. Verification: the Authorization Server's logs show a token-exchange attempt with a code_verifier mismatch, rejected before any token was issued. Prevention: PKCE is mandatory for all public clients per current OAuth security guidance — plus, where the platform supports it, use verified HTTPS "app links" / "universal links" as the redirect URI instead of a custom scheme, since those are cryptographically bound to one app by the OS.