4. Security Considerations

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. In particular, when authorization server details can be manually configured in the client, the client MUST ensure that the accepted iss values are unique for each authorization server.

Clients MÜSSEN den iss-Parameter genau wie in Abschnitt 2.4 beschrieben validieren und DÜRFEN NICHT zulassen, dass mehrere Autorisierungsserver denselben Aussteller-Identifikator verwenden. Insbesondere wenn Details zum Autorisierungsserver manuell im Client konfiguriert werden können, MUSS der Client sicherstellen, dass die akzeptierten iss-Werte für jeden Autorisierungsserver eindeutig sind.

The iss parameter enables a client to decide if an authorization server "expects" to be used in an OAuth flow together with a certain token endpoint and potentially other endpoints, like the userinfo endpoint [OIDC.Core]. When OAuth metadata is used, the iss parameter identifies the issuer and therefore the respective OAuth metadata document that points to the other endpoints. When OAuth metadata is not used, the client can use, for example, a statically configured expected iss value for each configured authorization server.

Der iss-Parameter ermöglicht es einem Client zu entscheiden, ob ein Autorisierungsserver "erwartet", in einem OAuth-Fluss zusammen mit einem bestimmten Token-Endpunkt und möglicherweise anderen Endpunkten, wie dem Userinfo-Endpunkt [OIDC.Core], verwendet zu werden. Wenn OAuth-Metadaten verwendet werden, identifiziert der iss-Parameter den Aussteller und damit das jeweilige OAuth-Metadatendokument, das auf die anderen Endpunkte verweist. Wenn keine OAuth-Metadaten verwendet werden, kann der Client zum Beispiel einen statisch konfigurierten erwarteten iss-Wert für jeden konfigurierten Autorisierungsserver verwenden.

The issuer identifier contained in the authorization response is not cryptographically protected against tampering. In general, mechanisms such as JWTs (as specified in [JARM]) could be used to protect the integrity of the authorization response. However, in mix-up attacks, the client generally receives the authorization response from an uncompromised authorization server. If an attacker can tamper with this authorization response before it is received by the client, the attacker would also have direct access to the authorization code. The attacker does not need to execute a mix-up attack to steal the authorization code. Therefore, integrity protection for the authorization response is not necessary to defend against mix-up attacks.

Der in der Autorisierungsantwort enthaltene Aussteller-Identifikator ist nicht kryptografisch gegen Manipulationen geschützt. Im Allgemeinen könnten Mechanismen wie JWTs (wie in [JARM] spezifiziert) verwendet werden, um die Integrität der Autorisierungsantwort zu schützen. Bei Mix-Up-Angriffen empfängt der Client jedoch im Allgemeinen die Autorisierungsantwort von einem nicht kompromittierten Autorisierungsserver. Wenn ein Angreifer diese Autorisierungsantwort manipulieren kann, bevor sie vom Client empfangen wird, hätte der Angreifer auch direkten Zugriff auf den Autorisierungscode. Der Angreifer muss keinen Mix-Up-Angriff ausführen, um den Autorisierungscode zu stehlen. Daher ist ein Integritätsschutz für die Autorisierungsantwort nicht erforderlich, um sich gegen Mix-Up-Angriffe zu verteidigen.

There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means and this identifier is checked as laid out in Section 2.4, the use and verification of the iss parameter is not necessary and MAY be omitted. For example, this is the case when OpenID Connect response types that return an ID Token from the authorization endpoint (e.g., response_type=code id_token) or [JARM] are used. However, if a client receives an authorization response that contains multiple issuer identifiers, the client MUST reject the response if these issuer identifiers do not match. The details of alternative countermeasures are outside of the scope of this specification.

Es gibt auch alternative Gegenmaßnahmen zu Mix-Up-Angriffen. Wenn eine Autorisierungsantwort bereits auf andere Weise den Aussteller-Identifikator eines Autorisierungsservers enthält und dieser Identifikator wie in Abschnitt 2.4 dargelegt überprüft wird, ist die Verwendung und Überprüfung des iss-Parameters nicht erforderlich und KANN weggelassen werden. Dies ist zum Beispiel der Fall, wenn OpenID Connect-Antworttypen verwendet werden, die ein ID-Token vom Autorisierungsendpunkt zurückgeben (z. B. response_type=code id_token) oder [JARM]. Wenn ein Client jedoch eine Autorisierungsantwort erhält, die mehrere Aussteller-Identifikatoren enthält, MUSS der Client die Antwort ablehnen, wenn diese Aussteller-Identifikatoren nicht übereinstimmen. Die Details alternativer Gegenmaßnahmen liegen außerhalb des Geltungsbereichs dieser Spezifikation.

Mix-up attacks are only relevant to clients that interact with multiple authorization servers. However, clients interacting with only one authorization server might add support for a second authorization server in the future. By supporting multiple authorization servers, they become vulnerable to mix-up attacks and need to apply countermeasures.

Mix-Up-Angriffe sind nur für Clients relevant, die mit mehreren Autorisierungsservern interagieren. Clients, die nur mit einem Autorisierungsserver interagieren, könnten jedoch in Zukunft Unterstützung für einen zweiten Autorisierungsserver hinzufügen. Durch die Unterstützung mehrerer Autorisierungsserver werden sie anfällig für Mix-Up-Angriffe und müssen Gegenmaßnahmen ergreifen.