1. Introduction
The OAuth 2.0 Authorization Framework [RFC6749] allows clients to interact with multiple independent authorization servers under the control of separate entities. Some OAuth grant types utilize the resource owner's user agent to deliver the authorization server's response to the OAuth client. One example of this pattern is the authorization response of the authorization code grant.
Das OAuth 2.0 Autorisierungs-Framework [RFC6749] ermöglicht es Clients, mit mehreren unabhängigen Autorisierungsservern unter der Kontrolle separater Entitäten zu interagieren. Einige OAuth-Grant-Typen nutzen den User-Agent des Ressourceninhabers, um die Antwort des Autorisierungsservers an den OAuth-Client zu übermitteln. Ein Beispiel für dieses Muster ist die Autorisierungsantwort des Authorization Code Grants.
The authorization response as specified in Section 4.1.2 of [RFC6749] does not contain any information about the identity of the authorization server that issued the response. Therefore, clients receiving a response from the resource owner's user agent cannot be sure who initially issued the response and the secrets contained therein. The lack of certainty about the origin of the response enables a class of attacks called "mix-up attacks".
Die in Abschnitt 4.1.2 von [RFC6749] spezifizierte Autorisierungsantwort enthält keine Informationen über die Identität des Autorisierungsservers, der die Antwort ausgestellt hat. Daher können Clients, die eine Antwort vom User-Agent des Ressourceninhabers erhalten, nicht sicher sein, wer die Antwort und die darin enthaltenen Geheimnisse ursprünglich ausgestellt hat. Die mangelnde Gewissheit über den Ursprung der Antwort ermöglicht eine Klasse von Angriffen, die als "Mix-Up-Angriffe" bezeichnet werden.
Mix-up attacks are a potential threat to all OAuth clients that interact with multiple authorization servers. When at least one of these authorization servers is under an attacker's control, the attacker can launch a mix-up attack to acquire authorization codes or access tokens issued by any one of the other authorization servers. There are multiple ways in which an attacker can gain control over an authorization server supported by the client; for instance, an authorization server could become compromised, or the attacker could register their own authorization server, for example, using dynamic client registration [RFC7591].
Mix-Up-Angriffe sind eine potenzielle Bedrohung für alle OAuth-Clients, die mit mehreren Autorisierungsservern interagieren. Wenn mindestens einer dieser Autorisierungsserver unter der Kontrolle eines Angreifers steht, kann der Angreifer einen Mix-Up-Angriff starten, um Autorisierungscodes oder Zugriffstoken zu erlangen, die von einem der anderen Autorisierungsserver ausgestellt wurden. Es gibt mehrere Möglichkeiten, wie ein Angreifer die Kontrolle über einen vom Client unterstützten Autorisierungsserver erlangen kann; zum Beispiel könnte ein Autorisierungsserver kompromittiert werden, oder der Angreifer könnte seinen eigenen Autorisierungsserver registrieren, beispielsweise unter Verwendung der dynamischen Client-Registrierung [RFC7591].
OAuth clients that interact with only one authorization server are not vulnerable to mix-up attacks. However, when such clients decide to add support for a second authorization server in the future, they become vulnerable and need to apply countermeasures to mix-up attacks.
OAuth-Clients, die nur mit einem Autorisierungsserver interagieren, sind nicht anfällig für Mix-Up-Angriffe. Wenn solche Clients jedoch beschließen, in Zukunft Unterstützung für einen zweiten Autorisierungsserver hinzuzufügen, werden sie anfällig und müssen Gegenmaßnahmen gegen Mix-Up-Angriffe ergreifen.
Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe threat to the confidentiality and integrity of resources whose access is managed with OAuth. A detailed description and different variants of the mix-up attack class can be found in Section 4.4 of "OAuth 2.0 Security Best Current Practice" [OAUTH-SECURITY-TOPICS] as well as in the original research first highlighting this attack class, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] and "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
Mix-Up-Angriffe zielen darauf ab, einen Autorisierungscode oder ein Zugriffstoken zu stehlen, indem der Client dazu gebracht wird, den Autorisierungscode oder das Zugriffstoken an den Angreifer statt an den ehrlichen Autorisierungs- oder Ressourcenserver zu senden. Dies stellt eine schwere Bedrohung für die Vertraulichkeit und Integrität von Ressourcen dar, deren Zugriff mit OAuth verwaltet wird. Eine detaillierte Beschreibung und verschiedene Varianten der Mix-Up-Angriffsklasse finden sich in Abschnitt 4.4 von "OAuth 2.0 Security Best Current Practice" [OAUTH-SECURITY-TOPICS] sowie in der ursprünglichen Forschung, die diese Angriffsklasse erstmals hervorhob, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] und "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
This document defines a new parameter in the authorization response called iss. The iss parameter allows the authorization server to include its identity in the authorization response explicitly. The client can compare the value of the iss parameter to the issuer identifier of the authorization server (e.g., retrieved from its metadata) it believes it is interacting with. The iss parameter gives the client certainty about the authorization server's identity and enables it to send credentials such as authorization codes and access tokens only to the intended recipients.
Dieses Dokument definiert einen neuen Parameter in der Autorisierungsantwort namens iss. Der iss-Parameter ermöglicht es dem Autorisierungsserver, seine Identität explizit in die Autorisierungsantwort aufzunehmen. Der Client kann den Wert des iss-Parameters mit dem Aussteller-Identifikator des Autorisierungsservers (z. B. aus dessen Metadaten abgerufen) vergleichen, mit dem er zu interagieren glaubt. Der iss-Parameter gibt dem Client Gewissheit über die Identität des Autorisierungsservers und ermöglicht es ihm, Anmeldeinformationen wie Autorisierungscodes und Zugriffstoken nur an die vorgesehenen Empfänger zu senden.
The effectiveness of the iss parameter against mix-up attacks was analyzed and formally proven in "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
Die Wirksamkeit des iss-Parameters gegen Mix-Up-Angriffe wurde in "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229] analysiert und formal bewiesen.
1.1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.
This specification uses the terms "access token", "authorization code", "authorization code grant", "authorization server", "resource server", "authorization response", "grant type", and "client" defined by the OAuth 2.0 Authorization Framework [RFC6749]. The term "issuer identifier" is defined by OAuth 2.0 Authorization Server Metadata [RFC8414].
Diese Spezifikation verwendet die Begriffe "Access Token", "Authorization Code", "Authorization Code Grant", "Authorization Server", "Resource Server", "Authorization Response", "Grant Type" und "Client", die durch das OAuth 2.0 Autorisierungs-Framework [RFC6749] definiert sind. Der Begriff "Issuer Identifier" (Aussteller-Identifikator) wird durch OAuth 2.0 Authorization Server Metadata [RFC8414] definiert.