5. Security Considerations (Considérations de sécurité)
5. Security Considerations (Considérations de sécurité)
Si le serveur d'autorisation ne prend pas en charge la révocation des jetons d'accès, les jetons d'accès ne seront pas immédiatement invalidés lorsque le jeton de rafraîchissement correspondant est révoqué. Les déploiements doivent prendre cela en compte lors de la réalisation de leur analyse des risques de sécurité.
Le nettoyage des jetons à l'aide de la révocation contribue à la sécurité et à la confidentialité globales car cela réduit la probabilité d'abus de jetons abandonnés. Cette spécification n'a généralement pas l'intention de fournir des contre-mesures contre le vol et l'abus de jetons. Pour une discussion sur les menaces et contre-mesures respectives, consultez les considérations de sécurité données à la Section 10 de la spécification principale OAuth [RFC6749] et le document de modèle de menace OAuth [RFC6819].
Les clients malveillants pourraient tenter d'utiliser le nouvel endpoint pour lancer des attaques par denial-of-service (déni de service) sur le serveur d'autorisation. Des contre-mesures appropriées, qui devraient être en place pour l'endpoint de jeton également, DOIVENT (MUST) être appliquées à l'endpoint de révocation (voir [RFC6819], Section 4.4.1.11). Plus précisément, des indices de type de jeton invalides peuvent induire le serveur d'autorisation en erreur et entraîner des recherches supplémentaires dans la base de données. Des précautions DOIVENT (MUST) être prises pour empêcher les clients malveillants d'exploiter cette fonctionnalité pour lancer des attaques par déni de service.
Un client malveillant peut tenter de deviner des jetons valides sur cet endpoint en effectuant des demandes de révocation contre des chaînes de jetons potentielles. Selon cette spécification, la demande d'un client doit contenir un client_id valide, dans le cas d'un client public, ou des identifiants client valides, dans le cas d'un client confidentiel. Le jeton révoqué doit également appartenir au client demandeur. Si un attaquant parvient à deviner avec succès le client_id d'un client public et l'un de ses jetons, ou les identifiants d'un client privé et l'un de ses jetons, il pourrait faire des dégâts bien pires en utilisant le jeton ailleurs qu'en le révoquant. S'il choisit de révoquer le jeton, le client légitime perdra son octroi d'autorisation et devra à nouveau solliciter l'utilisateur. Aucun autre dommage n'est causé et le jeton deviné est maintenant sans valeur.
Étant donné que l'endpoint de révocation gère des identifiants de sécurité, les clients ne doivent obtenir son emplacement qu'auprès d'une source digne de confiance. Sinon, un attaquant pourrait capturer des jetons de sécurité valides en utilisant un endpoint de révocation contrefait. De plus, afin de détecter les endpoints de révocation contrefaits, les clients DOIVENT (MUST) authentifier l'endpoint de révocation (validation de certificat, etc.).