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.
Il framework di autorizzazione OAuth 2.0 [RFC6749] consente ai client di interagire con più server di autorizzazione indipendenti sotto il controllo di entità separate. Alcuni tipi di concessione OAuth utilizzano lo user agent del proprietario della risorsa per consegnare la risposta del server di autorizzazione al client OAuth. Un esempio di questo modello è la risposta di autorizzazione della concessione del codice di autorizzazione.
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".
La risposta di autorizzazione come specificata nella Sezione 4.1.2 della [RFC6749] non contiene alcuna informazione sull'identità del server di autorizzazione che ha emesso la risposta. Pertanto, i client che ricevono una risposta dallo user agent del proprietario della risorsa non possono essere sicuri di chi abbia inizialmente emesso la risposta e i segreti in essa contenuti. La mancanza di certezza sull'origine della risposta consente una classe di attacchi chiamati "attacchi mix-up".
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].
Gli attacchi mix-up sono una potenziale minaccia per tutti i client OAuth che interagiscono con più server di autorizzazione. Quando almeno uno di questi server di autorizzazione è sotto il controllo di un attaccante, l'attaccante può lanciare un attacco mix-up per acquisire codici di autorizzazione o token di accesso emessi da uno qualsiasi degli altri server di autorizzazione. Ci sono diversi modi in cui un attaccante può ottenere il controllo su un server di autorizzazione supportato dal client; ad esempio, un server di autorizzazione potrebbe essere compromesso, oppure l'attaccante potrebbe registrare il proprio server di autorizzazione, ad esempio, utilizzando la registrazione dinamica del client [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.
I client OAuth che interagiscono con un solo server di autorizzazione non sono vulnerabili agli attacchi mix-up. Tuttavia, quando tali client decidono di aggiungere il supporto per un secondo server di autorizzazione in futuro, diventano vulnerabili e devono applicare contromisure agli attacchi mix-up.
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].
Gli attacchi mix-up mirano a rubare un codice di autorizzazione o un token di accesso inducendo il client a inviare il codice di autorizzazione o il token di accesso all'attaccante invece che al server di autorizzazione o di risorse onesto. Questo rappresenta una grave minaccia alla riservatezza e all'integrità delle risorse il cui accesso è gestito con OAuth. Una descrizione dettagliata e diverse varianti della classe di attacchi mix-up si trovano nella Sezione 4.4 di "OAuth 2.0 Security Best Current Practice" [OAUTH-SECURITY-TOPICS] così come nella ricerca originale che per prima ha evidenziato questa classe di attacchi, "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] e "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.
Questo documento definisce un nuovo parametro nella risposta di autorizzazione chiamato iss. Il parametro iss consente al server di autorizzazione di includere esplicitamente la propria identità nella risposta di autorizzazione. Il client può confrontare il valore del parametro iss con l'identificatore dell'emittente del server di autorizzazione (ad esempio, recuperato dai suoi metadati) con cui crede di interagire. Il parametro iss fornisce al client la certezza sull'identità del server di autorizzazione e gli consente di inviare credenziali come codici di autorizzazione e token di accesso solo ai destinatari previsti.
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].
L'efficacia del parametro iss contro gli attacchi mix-up è stata analizzata e formalmente dimostrata in "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229].
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.
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.
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].
Questa specifica utilizza i termini "access token", "authorization code", "authorization code grant", "authorization server", "resource server", "authorization response", "grant type" e "client" definiti dal framework di autorizzazione OAuth 2.0 [RFC6749]. Il termine "issuer identifier" (identificatore dell'emittente) è definito da OAuth 2.0 Authorization Server Metadata [RFC8414].