6. Privacy Considerations (Considerazioni sulla privacy)
Poiché i token di accesso JWT trasportano informazioni per valore, ora diventa possibile per i client e potenzialmente anche per gli utenti finali sbirciare direttamente all'interno della raccolta di claim dei token non crittografati.
Il client non deve (MUST NOT) ispezionare il contenuto del token di accesso: il server di autorizzazione e il server di risorse potrebbero decidere di modificare il formato del token in qualsiasi momento (ad esempio, passando da questo profilo a token opachi); di conseguenza, qualsiasi logica nel client che si basi sulla capacità di leggere il contenuto del token di accesso si romperebbe senza rimedio. Il framework OAuth 2.0 presume che i token di accesso siano trattati come opachi dai client. Gli amministratori dei server di autorizzazione dovrebbero anche tenere conto che il contenuto di un token di accesso è visibile al client. Ogni volta che l'accesso del client al contenuto del token di accesso presenta problemi di privacy per un determinato scenario, il server di autorizzazione deve adottare misure esplicite per prevenirli.
Negli scenari in cui i token di accesso JWT sono accessibili all'utente finale, dovrebbe essere valutato se le informazioni possano essere accessibili senza violazioni della privacy (ad esempio, se un utente finale accede semplicemente alle proprie informazioni personali) o se debbano essere adottate misure per garantire la riservatezza.
Le possibili misure per prevenire la fuga di informazioni verso i client e gli utenti finali includono: crittografare il token di accesso, crittografare i claim sensibili, omettere i claim sensibili o non utilizzare questo profilo, e ricorrere a token di accesso opachi.
In ogni scenario, il contenuto del token di accesso JWT sarà alla fine accessibile al server di risorse. È importante valutare se il server di risorse abbia ottenuto il diritto appropriato di accedere a qualsiasi contenuto ricevuto sotto forma di claim, ad esempio, attraverso il consenso dell'utente in qualche forma, politiche e accordi con l'organizzazione che gestisce i server di autorizzazione, ecc. Ad esempio, un utente potrebbe non voler acconsentire a concedere informazioni al server di risorse specifico su uno qualsiasi dei claim non obbligatori enumerati nella Sezione 2 (e nelle sue sottosezioni).
Questo profilo impone la presenza del claim "sub" in ogni token di accesso JWT, rendendo possibile per i server di risorse fare affidamento su tali informazioni per correlare le richieste in arrivo con i dati memorizzati localmente per il principale autenticato. Sebbene la capacità di correlare le richieste possa essere richiesta per progetto in molti scenari, ci sono scenari in cui il server di autorizzazione potrebbe voler impedire la correlazione. Il claim "sub" dovrebbe essere popolato dai server di autorizzazione secondo una valutazione dell'impatto sulla privacy. Ad esempio, se una soluzione richiede di impedire il monitoraggio delle attività del principale su più server di risorse, il server di autorizzazione dovrebbe assicurarsi che i token di accesso JWT destinati a diversi server di risorse abbiano valori "sub" distinti che non possano essere correlati in caso di collusione tra server di risorse. Allo stesso modo, se una soluzione richiede di impedire a un server di risorse di correlare l'attività del principale all'interno della risorsa stessa, il server di autorizzazione dovrebbe assegnare valori "sub" diversi per ogni token di accesso JWT emesso. A sua volta, il client dovrebbe ottenere un nuovo token di accesso JWT per ogni chiamata al server di risorse per garantire che il server di risorse riceva valori "sub" e "jti" diversi ad ogni chiamata, impedendo così la correlazione tra richieste distinte.