4. Public Clients and Certificate-Bound Tokens (Clients publics et jetons liés au certificat)

4. Public Clients and Certificate-Bound Tokens (Clients publics et jetons liés au certificat)

L'authentification client OAuth mutual-TLS et les jetons d'accès liés au certificat peuvent être utilisés indépendamment l'un de l'autre. L'utilisation de jetons d'accès liés au certificat sans authentification client OAuth mutual-TLS est par exemple possible pour lier les jetons d'accès à un certificat client TLS pour les clients publics (ceux sans identifiants d'authentification associés au client_id). Le serveur d'autorisation configurerait la pile TLS de la même manière que pour la méthode du certificat auto-signé, de sorte qu'elle ne vérifie pas que le certificat présenté par le client pendant la poignée de main est signé par une CA de confiance. Des instances individuelles d'un client créeraient un certificat auto-signé pour mutual TLS avec le serveur d'autorisation et le serveur de ressources. Le serveur d'autorisation n'utiliserait pas le certificat mutual-TLS pour authentifier le client au niveau OAuth mais lierait le jeton d'accès délivré au certificat pour lequel le client a prouvé la possession de la clé privée correspondante. Le jeton d'accès est alors lié au certificat et ne peut être utilisé que par le client possédant le certificat et la clé privée correspondante et les utilisant pour négocier mutual TLS sur les connexions vers le serveur de ressources. Lorsque le serveur d'autorisation délivre un jeton d'actualisation à un tel client, il DEVRAIT également lier le jeton d'actualisation au certificat respectif et vérifier la liaison lorsque le jeton d'actualisation est présenté pour obtenir de nouveaux jetons d'accès. Les détails d'implémentation de la liaison du jeton d'actualisation relèvent de la discrétion du serveur d'autorisation.