OAuth & Federated Identity

The user authenticates at the authorization server, which redirects back to the client with a short-lived code. The client exchanges that code for tokens on a direct server call. Only the code crosses the redirect, since redirect URLs reach logs.

state is an unguessable value the client generates, binds to the user session and sends on the authorization request. The server echoes it on the redirect, and a callback whose state does not match is rejected as forged.

The authorization server compares the requested redirect_uri against a pre-registered value string for string — scheme, host, port and path. Prefix or wildcard matching lets a lookalike URL resolve elsewhere, and the code is delivered there.

A JWT is header, payload and signature, base64url-encoded and joined by dots. Header and payload are encoded, not encrypted, so any holder reads them. Before trusting a claim the server verifies the signature, then checks iss, aud and exp.

The client makes a random code_verifier, sends its hash as code_challenge on the authorization request, then presents the verifier at the token endpoint. The code is redeemed only when they match, binding it to whoever started the flow.

The id_token is authentication output addressed to the client — its aud is the client id and it states who signed in. The access_token is authorization output addressed to the API. OAuth2 grants access; OIDC says who the user is.

A verifier that takes its algorithm from the token own alg header can be pushed from an asymmetric setup to a symmetric one, where the public key — which is not secret — becomes the HMAC key. Pin the expected algorithm and key per issuer.

The gateway decodes rather than verifies, so a token declaring no algorithm carries no signature yet is trusted. Verify with a pinned algorithm and the issuer published key, reject any other alg, and read claims only after that passes.

Client credentials fit a background service acting as itself — no user, no redirect, no consent. The client authenticates and gets a token carrying its own identity. Scopes say what it may do, so grant only the narrowest set the job needs.

Browser, mobile and server-side apps acting for a user all use authorization code with PKCE; callers with no user use client credentials. Implicit returned tokens in the URL and the password grant took real user credentials, so both are retired.

The client puts a random nonce in the authorization request and demands the same value inside the id_token, binding it to this login and blocking replay. It must also verify the signature and check iss, exp and aud.

Anything placed in a URL — a token in a fragment or query — reaches browser history, proxy logs and Referer headers, so tokens belong in headers. Audience restriction is separate: a token names its API, so another server rejects it.