2026-09-25 · 6 min read · Rahul Chitturi
- oauth
- security
- debugging
OAuth authorization response issuer identification adds an iss parameter so a client can confirm which authorization server produced a response. This is especially useful when one redirect URI serves registrations at several issuers and mix-up would otherwise be difficult to detect.
Failures appear when the returned value is compared with a token claim instead of the configured authorization-server issuer, an intermediary changes parameters, or support differs between clients and servers.
Bind the browser transaction
Store the expected issuer, client registration, redirect URI, state, PKCE context, and authorization endpoint when starting the request. At the redirect, retrieve that server-side transaction before processing a code or protocol error.
- Compare issuer identifiers using protocol-defined rules.
- Reject an unexpected or ambiguous response issuer.
- Keep state validation and issuer validation independent.
- Send the code only to the bound token endpoint.
Handle capability and errors explicitly
Record trusted discovery metadata and the provider's issuer-identification support. Define migration behavior for a server that omits iss rather than silently accepting both forms forever.
Validate the response issuer on error responses as well as successful code responses. Do not select an authorization server from an untrusted returned issuer and then fetch its metadata or send credentials to its endpoints.
Use synthetic redirect fixtures
Use Flashman's URL tool for harmless redirect responses, JSON formatter for sanitized metadata, JWT decoder only for disposable token structures, and diff for provider behavior. Redact real codes, state values, and credentials.
Test matching, missing, malformed, duplicate, encoded, and unexpected issuer values; success and error responses; concurrent logins at several issuers; stale state; redirect proxies; discovery changes; and token-endpoint binding.