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.

I client DEVONO convalidare il parametro iss precisamente come descritto nella Sezione 2.4 e NON DEVONO consentire a più server di autorizzazione di utilizzare lo stesso identificatore dell'emittente. In particolare, quando i dettagli del server di autorizzazione possono essere configurati manualmente nel client, il client DEVE garantire che i valori iss accettati siano univoci per ogni server di autorizzazione.

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.

Il parametro iss consente a un client di decidere se un server di autorizzazione "si aspetta" di essere utilizzato in un flusso OAuth insieme a un determinato endpoint di token e potenzialmente altri endpoint, come l'endpoint userinfo [OIDC.Core]. Quando vengono utilizzati i metadati OAuth, il parametro iss identifica l'emittente e quindi il rispettivo documento di metadati OAuth che punta agli altri endpoint. Quando i metadati OAuth non vengono utilizzati, il client può utilizzare, ad esempio, un valore iss atteso configurato staticamente per ciascun server di autorizzazione configurato.

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.

L'identificatore dell'emittente contenuto nella risposta di autorizzazione non è protetto crittograficamente contro le manomissioni. In generale, meccanismi come i JWT (come specificato in [JARM]) potrebbero essere utilizzati per proteggere l'integrità della risposta di autorizzazione. Tuttavia, negli attacchi mix-up, il client riceve generalmente la risposta di autorizzazione da un server di autorizzazione non compromesso. Se un attaccante può manomettere questa risposta di autorizzazione prima che venga ricevuta dal client, l'attaccante avrebbe anche accesso diretto al codice di autorizzazione. L'attaccante non ha bisogno di eseguire un attacco mix-up per rubare il codice di autorizzazione. Pertanto, la protezione dell'integrità per la risposta di autorizzazione non è necessaria per difendersi dagli attacchi mix-up.

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.

Ci sono anche contromisure alternative agli attacchi mix-up. Quando una risposta di autorizzazione include già l'identificatore dell'emittente di un server di autorizzazione con altri mezzi e questo identificatore viene controllato come indicato nella Sezione 2.4, l'uso e la verifica del parametro iss non sono necessari e POSSONO essere omessi. Ad esempio, questo è il caso quando vengono utilizzati tipi di risposta OpenID Connect che restituiscono un token ID dall'endpoint di autorizzazione (ad esempio, response_type=code id_token) o [JARM]. Tuttavia, se un client riceve una risposta di autorizzazione che contiene più identificatori dell'emittente, il client DEVE rifiutare la risposta se questi identificatori dell'emittente non corrispondono. I dettagli delle contromisure alternative esulano dallo scopo di questa specifica.

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.

Gli attacchi mix-up sono rilevanti solo per i client che interagiscono con più server di autorizzazione. Tuttavia, i client che interagiscono con un solo server di autorizzazione potrebbero aggiungere il supporto per un secondo server di autorizzazione in futuro. Supportando più server di autorizzazione, diventano vulnerabili agli attacchi mix-up e devono applicare contromisure.