5. Security Considerations (Considerazioni sulla sicurezza)
Il layout dei dati del token di accesso JWT descritto qui è molto simile a quello dell'id_token come definito da [OpenID.Core]. La tipizzazione esplicita richiesta in questo profilo, in linea con le raccomandazioni in [RFC8725], aiuta il server di risorse a distinguere tra token di accesso JWT e token ID di OpenID Connect.
I server di autorizzazione dovrebbero impedire scenari in cui i client possono influenzare il valore del claim "sub" in modi che potrebbero confondere i server di risorse. Ad esempio, se il server di autorizzazione sceglie di utilizzare il client_id come valore "sub" per i token di accesso emessi utilizzando la concessione delle credenziali del client (Client Credentials Grant), il server di autorizzazione dovrebbe impedire ai client di registrare un valore client_id arbitrario, poiché ciò consentirebbe ai client malevoli di selezionare il sub di un proprietario di risorse ad alto privilegio e confondere qualsiasi logica di autorizzazione sul server di risorse che si basa sul valore "sub". Per ulteriori dettagli, si prega di fare riferimento alla Sezione 4.14 di [OAuth2.Security.BestPractices].
Per prevenire la confusione tra JWT (Cross-JWT Confusion), i server di autorizzazione devono (MUST) utilizzare un identificatore distinto come valore del claim "aud" per identificare in modo univoco i token di accesso emessi dallo stesso emittente per risorse distinte. Per ulteriori dettagli sulla confusione tra JWT, si prega di fare riferimento alla Sezione 2.8 di [RFC8725].
I server di autorizzazione dovrebbero prestare particolare attenzione quando gestiscono richieste che potrebbero portare a concessioni di autorizzazione ambigue. Ad esempio, se una richiesta include più indicatori di risorsa, il server di autorizzazione dovrebbe assicurarsi che ogni stringa di ambito inclusa nel token di accesso JWT risultante, se presente, possa essere correlata in modo non ambiguo a una risorsa specifica tra quelle elencate nel claim "aud". I dettagli su come riconoscere e mitigare questa e altre situazioni ambigue dipendono fortemente dallo scenario e sono quindi al di fuori dell'ambito di questo profilo.
I server di autorizzazione non possono fare affidamento sull'uso di chiavi diverse per firmare i token ID di OpenID Connect e i token JWT come metodo per salvaguardarsi dalle conseguenze della perdita di chiavi specifiche. Dato che i server di risorse non hanno modo di sapere quale chiave dovrebbe essere utilizzata per validare specificamente i token di accesso JWT, devono accettare firme eseguite con qualsiasi delle chiavi pubblicate nei metadati AS o nella scoperta OpenID Connect; di conseguenza, un attaccante deve solo compromettere qualsiasi chiave tra quelle pubblicate per essere in grado di generare e firmare JWT che saranno accettati come validi dal server di risorse.