proceed with the authorization grant.

Condition: when the iss value does not match the expected issuer identifier

Clients [...] MUST NOT proceed with the authorization grant.

assume an error response originated from the intended authorization server.

Condition: when issuer validation fails

For error responses, clients MUST NOT assume that the error originates from the intended authorization server.

allow multiple authorization servers to use the same issuer identifier.

Clients [...] MUST NOT allow multiple authorization servers to use the same issuer identifier.

extract the iss value from a received authorization response.

Condition: when supporting RFC 9207 and the parameter is present

Clients that support this specification MUST extract the value of the iss parameter [...] if the parameter is present.

form-decode the iss value and compare it with the expected issuer identifier.

Condition: after extracting a present iss parameter

Clients MUST then decode the value [...] and compare the result to the issuer identifier of the authorization server where the authorization request was sent to.

use simple string comparison when comparing issuer identifiers.

Condition: when validating the iss value

This comparison MUST use simple string comparison as defined in Section 6.2.1 of [RFC3986].

reject the authorization response.

Condition: when the iss value does not match the expected issuer identifier

If the value does not match the expected issuer identifier, clients MUST reject the authorization response.

compare the authorization response iss value with the metadata issuer value.

Condition: when interacting with an authorization server supporting OAuth metadata

Clients that interact with authorization servers supporting OAuth metadata [RFC8414] MUST compare the iss parameter value to the issuer value in the server's metadata document.

use deployment-specific means to determine the expected issuer value.

Condition: when OAuth authorization server metadata is not used

If OAuth metadata is not used, clients MUST use deployment-specific ways [...] to decide if the returned iss value is the expected value.

retain per-authorization-server state indicating iss support.

Condition: when interacting with both supporting and non-supporting authorization servers

Clients MUST retain state about whether each authorization server supports the iss parameter.

reject authorization responses that omit iss.

Condition: when the authorization server supports iss according to the client's configuration

Clients MUST reject authorization responses without the iss parameter from authorization servers that do support the parameter according to the client's configuration.

require the response iss value to be identical to the ID Token iss claim.

Condition: in an OpenID Connect flow where an ID Token is returned from the authorization endpoint

The value in the iss parameter MUST always be identical to the iss claim in the ID Token.

validate iss precisely as specified in RFC 9207 Section 2.4.

Clients MUST validate the iss parameter precisely as described in Section 2.4.

ensure accepted iss values are unique for each authorization server.

Condition: when authorization server details can be manually configured

The client MUST ensure that the accepted iss values are unique for each authorization server.

reject an authorization response containing nonmatching issuer identifiers.

Condition: when the response contains multiple issuer identifiers

The client MUST reject the response if these issuer identifiers do not match.

discard authorization responses containing iss.

Condition: when the authorization server does not indicate support for iss

Clients SHOULD discard authorization responses with the iss parameter from authorization servers that do not indicate their support for the parameter.

accept authorization responses that omit iss.

Condition: when supporting RFC 9207, subject to local policy or configuration

Clients that support this specification MAY accept authorization responses that do not contain the iss parameter.

omit use and verification of the standalone iss parameter.

Condition: when the response already includes an authorization server issuer identifier by another means and that identifier is validated as specified

The use and verification of the iss parameter is not necessary and MAY be omitted.

include the iss parameter in authorization responses, including error responses.

Condition: when supporting RFC 9207

An authorization server supporting this specification MUST indicate its identity by including the iss parameter in the response.

use an iss value that is an HTTPS URL without query or fragment components.

Condition: when including the iss parameter

Its value MUST be a URL that uses the "https" scheme without any query or fragment components.

provide its issuer identifier to clients.

Condition: when supporting RFC 9207

Authorization servers supporting this specification MUST provide their issuer identifier.

make the metadata issuer value identical to the authorization response iss value.

Condition: when publishing metadata according to RFC 8414

The issuer identifier included in the server's metadata value issuer MUST be identical to the iss parameter's value.

set authorization_response_iss_parameter_supported to true.

Condition: when publishing RFC 8414 metadata and supporting RFC 9207

The server MUST indicate its support for the iss parameter by setting the metadata parameter authorization_response_iss_parameter_supported [...] to true.

provide the issuer identifier through another mechanism.

Condition: in addition to the mechanism required by RFC 9207

Authorization servers MAY additionally provide the issuer identifier to clients by any other mechanism.