6. Privacy Considerations (Considérations relatives à la vie privée)
Étant donné que les jetons d'accès JWT transportent des informations par valeur, il devient désormais possible pour les clients et potentiellement même pour les utilisateurs finaux de regarder directement à l'intérieur de la collection de revendications des jetons non chiffrés.
Le client ne doit pas (MUST NOT) inspecter le contenu du jeton d'accès : le serveur d'autorisation et le serveur de ressources peuvent décider de modifier le format du jeton à tout moment (par exemple, en passant de ce profil à des jetons opaques) ; par conséquent, toute logique dans le client s'appuyant sur la capacité de lire le contenu du jeton d'accès se romprait sans recours. Le cadre OAuth 2.0 suppose que les jetons d'accès sont traités comme opaques par les clients. Les administrateurs de serveurs d'autorisation doivent également prendre en compte que le contenu d'un jeton d'accès est visible par le client. Chaque fois que l'accès du client au contenu du jeton d'accès présente des problèmes de confidentialité pour un scénario donné, le serveur d'autorisation doit prendre des mesures explicites pour les prévenir.
Dans les scénarios où les jetons d'accès JWT sont accessibles à l'utilisateur final, il convient d'évaluer si les informations peuvent être consultées sans violation de la vie privée (par exemple, si un utilisateur final accède simplement à ses propres informations personnelles) ou si des mesures doivent être prises pour garantir la confidentialité.
Les mesures possibles pour prévenir la fuite d'informations vers les clients et les utilisateurs finaux incluent : le chiffrement du jeton d'accès, le chiffrement des revendications sensibles, l'omission des revendications sensibles ou le non-utilisation de ce profil, et le repli sur des jetons d'accès opaques.
Dans tous les scénarios, le contenu du jeton d'accès JWT sera finalement accessible au serveur de ressources. Il est important d'évaluer si le serveur de ressources a obtenu le droit approprié d'avoir accès à tout contenu reçu sous forme de revendications, par exemple, par le biais du consentement de l'utilisateur sous une certaine forme, de politiques et d'accords avec l'organisation exploitant les serveurs d'autorisation, etc. Par exemple, un utilisateur peut ne pas souhaiter consentir à accorder des informations au serveur de ressources concernant l'une des revendications non obligatoires énumérées dans la Section 2 (et ses sous-sections).
Ce profil impose la présence de la revendication "sub" dans chaque jeton d'accès JWT, ce qui permet aux serveurs de ressources de s'appuyer sur ces informations pour corréler les demandes entrantes avec les données stockées localement pour le principal authentifié. Bien que la capacité de corréler les demandes puisse être requise par conception dans de nombreux scénarios, il existe des scénarios où le serveur d'autorisation peut vouloir empêcher la corrélation. La revendication "sub" devrait être renseignée par les serveurs d'autorisation selon une évaluation de l'impact sur la vie privée. Par exemple, si une solution nécessite d'empêcher le suivi des activités du principal sur plusieurs serveurs de ressources, le serveur d'autorisation devrait s'assurer que les jetons d'accès JWT destinés à différents serveurs de ressources ont des valeurs "sub" distinctes qui ne peuvent pas être corrélées en cas de collusion entre serveurs de ressources. De même, si une solution nécessite d'empêcher un serveur de ressources de corréler l'activité du principal au sein de la ressource elle-même, le serveur d'autorisation devrait attribuer des valeurs "sub" différentes pour chaque jeton d'accès JWT émis. À son tour, le client devrait obtenir un nouveau jeton d'accès JWT pour chaque appel au serveur de ressources afin de garantir que le serveur de ressources reçoive des valeurs "sub" et "jti" différentes à chaque appel, empêchant ainsi la corrélation entre des demandes distinctes.