OAuth 2.0 Authorization Server Issuer Identification
Extracted elements (20)
The `iss` parameter enables clients to explicitly verify the identity of the authorization server that issued a response, countering mix-up attacks where an attacker-controlled authorization server tricks the client into sending credentials to the wrong party. Its effectiveness was formally proven in Fett et al. [arXiv.1601.01229].
When JARM (JWT Secured Authorization Response Mode) is used, the JWT already contains an `iss` claim that provides equivalent mix-up protection if validated per Section 2.4. An additional `iss` parameter outside the JWT is therefore not necessary when JARM is in use.
Per RFC 6749 §4.1.2, clients that do not support this specification MUST ignore the unrecognized `iss` parameter, ensuring backward compatibility with existing deployments.
An authorization server supporting this specification MUST indicate its identity by including the `iss` parameter in every authorization response it sends to the client, including error responses.
Clients interacting with authorization servers that publish OAuth metadata (RFC 8414) MUST compare the `iss` parameter value to the `issuer` value in the server's metadata document. If OAuth metadata is not used, clients MUST use deployment-specific means (e.g., static configuration) to verify the expected `iss` value.
Clients interacting with both supporting and non-supporting authorization servers MUST retain state about whether each authorization server supports the `iss` parameter. Clients MUST reject authorization responses without `iss` from servers that, per client configuration, do support it.
Clients MUST extract the `iss` parameter from authorization responses if present, decode it from application/x-www-form-urlencoded form, and compare it to the issuer identifier of the authorization server where the request was sent. Comparison MUST use simple string comparison per RFC 3986 §6.2.1.
Clients MUST validate the `iss` parameter precisely as described in Section 2.4 and MUST NOT allow multiple authorization servers to use the same issuer identifier. When authorization server details are manually configured, the client MUST ensure accepted `iss` values are unique per server.
Clients SHOULD discard authorization responses containing an `iss` parameter from authorization servers that do not indicate support for the parameter in their metadata, though local policy may permit accepting such responses.
For authorization servers publishing RFC 8414 metadata, the `issuer` metadata value MUST be identical to the `iss` parameter value, and the server MUST set `authorization_response_iss_parameter_supported` to true to indicate support.
If a client receives an authorization response that contains multiple issuer identifiers (e.g., both an `iss` parameter and an ID Token `iss` claim), the client MUST reject the response if these identifiers do not match.
If the `iss` value does not match the expected issuer identifier, clients MUST reject the authorization response and MUST NOT proceed with the authorization grant. For error responses, clients MUST NOT assume the error originates from the intended authorization server.
In OpenID Connect flows where an ID Token is returned from the authorization endpoint, the value of the `iss` parameter MUST always be identical to the `iss` claim in the ID Token.
The value of the `iss` parameter MUST be a URL that uses the "https" scheme without any query or fragment components.
The `authorization_response_iss_parameter_supported` boolean metadata parameter signals whether the authorization server includes the `iss` parameter in its authorization responses. If omitted, the default value is false.
The `iss` parameter is added to authorization responses (including error responses). Its value is the issuer identifier of the authorization server that created the response, as defined in RFC 8414. It MUST be a URL using the "https" scheme without any query or fragment components.
IANA registered `authorization_response_iss_parameter_supported` in the "OAuth Authorization Server Metadata" registry (established by RFC 8414). It is a boolean indicating whether the AS provides the `iss` parameter in the authorization response.
IANA updated the `iss` entry in the "OAuth Parameters" registry (established by RFC 6749). Its usage location covers both authorization request and authorization response, with specification documents RFC 9207, RFC 9101, and RFC 7519 §4.1.1.
Mix-up attacks are only relevant to clients interacting with multiple authorization servers. Clients currently using a single authorization server must still apply countermeasures when they add support for a second, as adding multi-AS support makes them newly vulnerable.
The issuer identifier in the authorization response is not cryptographically protected against tampering. However, integrity protection is not necessary to defend against mix-up attacks: if an attacker can tamper with the authorization response, they already have direct access to the authorization code and do not need a mix-up attack.