2026-09-25 · 8 min read
- oauth
- security
- architecture
A client using several authorization servers can receive every browser redirect at the same endpoint. Without a reliable binding to the issuer selected at request time, a response can be confused with one from another server.
OAuth authorization response issuer identification provides an iss response parameter that lets the client compare the response's claimed origin with the issuer already bound to the browser transaction.
Create a server-side transaction record
When starting authorization, store an opaque transaction identifier linked to the expected issuer, client registration, authorization and token endpoints, redirect URI, state, PKCE challenge context, nonce where applicable, creation time, and return destination.
- Keep the record short-lived and single-use.
- Bind cookies with appropriate browser protections.
- Do not encode credentials in front-channel state.
- Partition records by environment and tenant.
Validate before exchanging the code
At the redirect endpoint, locate the transaction with constant-time, unguessable state handling. Parse parameters with duplicate detection, compare the returned iss using the specification's issuer-identifier rules, and reject missing or mismatched values according to the negotiated profile.
Only after issuer and state checks pass should the client send the authorization code to the token endpoint already stored in the transaction. Never discover endpoints from the untrusted response parameter.
Cover protocol error responses
Apply issuer identification to authorization errors as well as successful code responses. Preserve enough safe context to report the correct provider and failure class, but do not reflect raw error descriptions into HTML without escaping.
Keep issuer, state, PKCE, nonce, redirect URI, token issuer, and ID-token validation as separate controls. One successful comparison does not replace the others.
Migrate heterogeneous providers
Record trusted metadata and provider capability per registration. If legacy servers omit iss, use a time-bounded compatibility mode based on the original transaction binding and provider-specific risk review, then measure and remove that mode.
Avoid a global accept-missing setting that weakens issuers which do support the defense. Coordinate authorization-server and client rollouts, and make fallback decisions observable without logging codes or personal data.
Exercise mix-up scenarios
Use Flashman's URL parser for synthetic responses, JSON formatter for sanitized metadata, JWT decoder for disposable structures, diff for provider traces, and hash tool for public fixtures. Use maintained OAuth libraries in production.
Test matching, missing, malformed, duplicate, and unexpected iss values; success and error responses; simultaneous flows at different issuers; stale and replayed state; redirects through proxies; metadata rotation; token-endpoint substitution; and rollback.