5. Security Considerations (Considérations de sécurité)
La disposition des données du jeton d'accès JWT décrite ici est très similaire à celle de l'id_token tel que défini par [OpenID.Core]. Le typage explicite requis dans ce profil, conformément aux recommandations de [RFC8725], aide le serveur de ressources à distinguer les jetons d'accès JWT des jetons d'identité OpenID Connect.
Les serveurs d'autorisation devraient empêcher les scénarios où les clients peuvent affecter la valeur de la revendication "sub" de manière à pouvoir confondre les serveurs de ressources. Par exemple, si le serveur d'autorisation choisit d'utiliser le client_id comme valeur "sub" pour les jetons d'accès émis en utilisant l'octroi d'informations d'identification du client (Client Credentials Grant), le serveur d'autorisation devrait empêcher les clients d'enregistrer une valeur client_id arbitraire, car cela permettrait à des clients malveillants de sélectionner le sub d'un propriétaire de ressource hautement privilégié et de confondre toute logique d'autorisation sur le serveur de ressources s'appuyant sur la valeur "sub". Pour plus de détails, veuillez vous référer à la Section 4.14 de [OAuth2.Security.BestPractices].
Pour prévenir la confusion entre JWT (Cross-JWT Confusion), les serveurs d'autorisation doivent (MUST) utiliser un identifiant distinct comme valeur de revendication "aud" pour identifier de manière unique les jetons d'accès émis par le même émetteur pour des ressources distinctes. Pour plus de détails sur la confusion entre JWT, veuillez vous référer à la Section 2.8 de [RFC8725].
Les serveurs d'autorisation devraient faire particulièrement attention lors du traitement des demandes susceptibles de conduire à des octrois d'autorisation ambigus. Par exemple, si une demande inclut plusieurs indicateurs de ressources, le serveur d'autorisation devrait s'assurer que chaque chaîne de portée incluse dans le jeton d'accès JWT résultant, le cas échéant, peut être corrélée de manière non ambiguë à une ressource spécifique parmi celles listées dans la revendication "aud". Les détails sur la façon de reconnaître et d'atténuer cette situation et d'autres situations ambiguës dépendent fortement du scénario et sont donc hors du champ d'application de ce profil.
Les serveurs d'autorisation ne peuvent pas s'appuyer sur l'utilisation de clés différentes pour signer les jetons d'identité OpenID Connect et les jetons JWT comme méthode pour se protéger contre les conséquences de la fuite de clés spécifiques. Étant donné que les serveurs de ressources n'ont aucun moyen de savoir quelle clé doit être utilisée pour valider spécifiquement les jetons d'accès JWT, ils doivent accepter les signatures effectuées avec n'importe laquelle des clés publiées dans les métadonnées AS ou la découverte OpenID Connect ; par conséquent, un attaquant n'a besoin que de compromettre n'importe quelle clé parmi celles publiées pour être en mesure de générer et de signer des JWT qui seront acceptés comme valides par le serveur de ressources.