Summary

  • RFC 9207 gives an OAuth client a narrow receipt: the issuer named in an authorization response must equal the issuer recorded for that request. A mismatch ends the flow before the client sends a code or token to the wrong endpoint.
  • The iss value identifies the authorization-server context. It does not authenticate the user, validate the authorization code, prove token issuance, establish audience or scope, or show that a resource server accepted an action.
  • Safe operation therefore joins separate records for request state, expected issuer, metadata, returned issuer, comparison and abort result, code redemption, token validation, resource decision and recovery.

The dangerous callback looks ordinary.

The browser returns to a registered redirect URI. The state value matches what the client created. The response carries an authorization code produced by an honest authorization server. No password has been phished and no code has been forged. Yet a client that works with more than one authorization server can still make a fatal routing mistake: it can send that honest code to a token endpoint controlled by the attacker.

The error lies between two individually plausible records. One says which authorization server the client thought it was using when the request began. The other is an authorization response delivered through the user's browser. OAuth 2.0's original response did not explicitly identify the server that created it. If the client lets browser routing, a generic callback or hostile metadata collapse those records, a valid code can cross into the wrong operator's hands.

RFC 9207 gives that gap a deliberately small repair. OAuth 2.0 Authorization Server Issuer Identification, published in March 2022 as an IETF Standards Track document, is collective work by Karsten Meyer zu Selhausen and Daniel Fett. It defines an iss parameter for the authorization response. A server supporting the specification includes its issuer identifier in successful and error responses. The client compares that value with the issuer it recorded for the authorization server to which it sent the request.

If the two strings do not match, the client rejects the response and does not proceed with the grant.

That is the whole authority of the field—and exactly why it matters.

The callback was missing its sender

OAuth deliberately separates roles. The resource owner uses a user agent. A client asks an authorization server for a grant. The client later presents that grant to a token endpoint. An access token is finally used at a resource server. The separation enables many services to compose, but it also creates routing choices whose safety cannot be inferred from the browser's arrival alone.

RFC 6749 gave the authorization response a code and, when the request included it, the same state value. That state is essential. It binds a response to the user's authenticated browser state and helps stop cross-site request forgery. It does not answer a different question: which authorization server issued the response?

For a client configured with only one authorization server, the distinction may be invisible because there is no competing endpoint bundle. Add a second server, however, and the client must remember more than “an OAuth flow is pending.” It must remember which issuer owns that flow. RFC 9700, the current OAuth security Best Current Practice, states the rule plainly: a multi-authorization-server client must prevent mix-up attacks and bind the intended issuer to each authorization request.

This is a useful example of Daniel Fett's public research record without turning a collective standard into a personal mythology. Fett's first-party site describes his work on identity and web-protocol security, OAuth and OpenID Connect. His IETF record lists RFC 9207 among four RFCs as observed in September 2026. Those facts explain the continuity of the problem. They do not make him the sole inventor of the response parameter or the operator of any deployed client.

One issuer, one endpoint bundle

An issuer identifier is not merely a display name. Under RFC 8414, it is an HTTPS URL without a query or fragment. It anchors an authorization-server metadata document that can identify the authorization endpoint, token endpoint, key locations and other capabilities. A single hostname may even host multiple issuers distinguished by path.

That bundle is the economic and operational object at risk. A client may show the user an honest authorization page yet be configured with an attacker-controlled token endpoint. RFC 9700 warns that storing an authorization endpoint URL alone is not enough: a malicious party can claim an honest authorization endpoint while declaring its own token endpoint. The client needs the issuer as the stable identifier for the endpoint set it intends to use.

RFC 9207 connects the browser-delivered response back to that set. When metadata is used, the response iss must exactly equal the metadata issuer, and the metadata can advertise authorization_response_iss_parameter_supported as true. The client extracts the returned value, decodes its form encoding and uses simple string comparison against the expected issuer for the request.

No fuzzy normalization is authorized. A path difference, an unexpected slash or a different issuer on the same host is not “close enough.” The point is not human resemblance. The point is deterministic routing.

The comparison creates a local decision surface. The authorization server states its identity. Metadata describes the endpoint bundle. The client records which issuer it selected, retains the server's support status and decides whether the returned value is admissible. No global coordinator executes that comparison. Each client owns the configuration and the abort.

A match is permission to continue, not proof of completion

The cleanest way to misuse iss is to make it mean too much.

A matching issuer does not authenticate the resource owner. The authorization server may still require login or may return an error. It does not prove that the user understood or intended the requested scope. That belongs to the authorization interaction and application policy.

The match does not validate the authorization code. After the client chooses the correct token endpoint, that endpoint must still verify the code, client identity where applicable, redirect URI and other grant conditions. The code may be expired, replayed, bound to another client or otherwise invalid.

Nor does the match prove that a token was issued. It says nothing by itself about token type, audience, scope, lifetime, sender constraint or revocation state. A resource server must make its own decision when the token is presented. Even a valid, correctly scoped token does not prove the application action succeeded or that the user received the expected result.

The receipts therefore form a sequence:

  1. The client created a request and stored the intended issuer with browser-bound state.
  2. The browser returned an authorization response.
  3. The response named an issuer.
  4. The client compared that issuer with the stored issuer and accepted or aborted.
  5. The client selected endpoints from validated metadata or equivalent static configuration.
  6. The token endpoint accepted or rejected the code.
  7. Any token was validated and enforced by the resource server.
  8. The application observed an outcome and retained enough evidence to investigate or reverse it.

RFC 9207 owns step four. Calling step four “OAuth success” erases every decision after it.

The field is not a signature

The iss parameter in the ordinary authorization response is not cryptographically protected. RFC 9207 says so directly. That sounds like a contradiction only if the field is treated as a universal authentication certificate.

The stated threat is narrower. In a mix-up attack, the client receives a response created by an uncompromised authorization server but is confused about which endpoint set should receive the code. If an attacker can alter that honest response before the client receives it, the attacker can already read the authorization code and does not need the mix-up route. The field prevents the routing confusion inside the model; it does not claim integrity against every attacker.

Where an integrity-protected authorization response is required, other mechanisms can carry the issuer. JARM, for example, puts response parameters in a signed JWT. OpenID Connect flows that return an ID Token from the authorization endpoint can also convey an issuer, provided the client validates it according to the required rules. If multiple issuer identifiers appear and disagree, the response must be rejected.

This is minimum initial specification in practice. Add the smallest shared signal that exposes the ambiguity. Leave stronger envelopes, supported-server policy and migration choices to systems that need them. The field does not outlaw alternative defenses; RFC 9700 also permits distinct redirect URIs per issuer when the client checks them correctly.

Legacy support is an explicit policy

Real clients do not upgrade every authorization server at once. RFC 9207 therefore distinguishes support state rather than pretending deployment is universal.

A client that knows a server supports the parameter must reject a response from that server when iss is missing. A server can advertise support in metadata. If a server is known not to support the parameter, the client may accept a response without it or refuse such servers entirely. Local configuration decides. The client should be cautious when a server sends iss without advertising support, because an unplanned parameter can signal inconsistent configuration.

This flexibility is not a loophole. It is where operator responsibility lives. A multi-issuer client needs an inventory of issuers, their endpoint metadata, the expected support bit, the date and source of that belief, the legacy exception if any, and the owner who can remove it. Otherwise “compatibility” becomes an indefinite route around the defense.

The transition also changes when the system adds a second authorization server. A single-issuer client may not need a mix-up defense today. The moment it adds another issuer, the old assumption expires. Product expansion therefore creates a security migration: issuer state must become request-specific before the new provider enters service.

The receipt an operator can actually test

Standards conformance cannot be established by reading metadata once. A useful operating test begins at request creation and follows the branch.

Record the request identifier, user-agent binding, selected issuer, metadata version, authorization and token endpoints, support flag and redirect URI. On return, record whether iss was present, its decoded value, the exact expected value, the comparison result and whether code redemption was suppressed on mismatch. Test successful responses, authorization errors, missing values, duplicate values, unknown issuers and two issuers sharing a host with different paths.

Then verify the negative promise. When the issuer mismatches, no request containing the code, client credential or token should reach the unexpected endpoint. Logs at the client and controlled test endpoints must agree. A user-visible error without a blocked network request is not a defense receipt.

Finally, keep the layers apart in incident reporting. An issuer mismatch identifies a failed identity comparison; it does not prove compromise. A token-endpoint rejection proves that endpoint refused one grant; it does not prove the authorization response was malicious. A resource denial is not retroactive evidence that issuer binding worked. Each event narrows a different uncertainty.

The field succeeds when it makes one ambiguity impossible to ignore. It gives the client a name it can compare before it moves a credential. It does not relieve the client, authorization server, token endpoint or resource server of the decisions they alone can make.

Sources