10. Considérations de sécurité (Security Considerations)
En tant que cadre flexible et extensible, les considérations de sécurité d'OAuth dépendent de nombreux facteurs. Les sections suivantes fournissent aux implémenteurs des directives de sécurité axées sur les trois profils de client décrits dans la section 2.1 : application Web, application basée sur un agent utilisateur et application native.
Un modèle et une analyse de sécurité OAuth complets, ainsi que le contexte de la conception du protocole, sont fournis par [OAuth-THREATMODEL].
10.1. Authentification du client (Client Authentication)
Le serveur d'autorisation (Authorization Server) établit des informations d'identification de client avec les clients d'application Web à des fins d'authentification du client. Le serveur d'autorisation est encouragé à considérer des moyens d'authentification du client plus solides qu'un mot de passe client. Les clients d'application Web doivent (MUST) assurer la confidentialité des mots de passe client et autres informations d'identification de client.
Le serveur d'autorisation ne doit pas (MUST NOT) émettre de mots de passe client ou d'autres informations d'identification de client aux clients d'application native ou d'application basée sur un agent utilisateur à des fins d'authentification du client. Le serveur d'autorisation peut (MAY) émettre un mot de passe client ou d'autres informations d'identification pour une installation spécifique d'un client d'application native sur un appareil spécifique.
Lorsque l'authentification du client n'est pas possible, le serveur d'autorisation devrait (SHOULD) employer d'autres moyens pour valider l'identité du client - par exemple, en exigeant l'enregistrement de l'URI de redirection du client ou en demandant au propriétaire de ressource (Resource Owner) de confirmer l'identité.
10.2. Usurpation d'identité du client (Client Impersonation)
Un client malveillant peut usurper l'identité d'un autre client et obtenir l'accès à des ressources protégées si le client usurpé ne parvient pas à, ou est incapable de, garder ses informations d'identification de client confidentielles.
Le serveur d'autorisation doit (MUST) authentifier le client chaque fois que possible. Si le serveur d'autorisation ne peut pas authentifier le client en raison de la nature du client, le serveur d'autorisation doit (MUST) exiger l'enregistrement de tout URI de redirection utilisé pour recevoir des réponses d'autorisation et devrait (SHOULD) utiliser d'autres moyens pour protéger les propriétaires de ressources de tels clients potentiellement malveillants.
10.3. Jetons d'accès (Access Tokens)
Les informations d'identification de jeton d'accès (Access Token) (le jeton d'accès et le secret émis par le serveur d'autorisation) peuvent être utilisées pour obtenir l'accès au serveur de ressources (Resource Server). Les informations d'identification de jeton d'accès doivent (MUST) être protégées contre tout accès non autorisé.
Les jetons d'accès ont généralement une durée de vie limitée et peuvent être rafraîchis lorsqu'ils expirent. Cependant, de tels jetons peuvent être interceptés et utilisés par un attaquant. Les mesures pour atténuer l'impact sur la sécurité incluent l'émission de jetons avec une durée de vie courte et une portée limitée.
10.4. Jetons de rafraîchissement (Refresh Tokens)
Le serveur d'autorisation peut (MAY) appliquer des exigences de stockage strictes pour les jetons de rafraîchissement (Refresh Token). Par exemple, le serveur d'autorisation peut limiter la durée de vie du jeton de rafraîchissement ou limiter la portée du jeton de rafraîchissement.
Le serveur d'autorisation doit (MUST) maintenir un lien entre le jeton de rafraîchissement et le client auquel il a été émis. Le jeton de rafraîchissement doit (MUST) être utilisé uniquement par le client auquel il a été émis.
10.5. Codes d'autorisation (Authorization Codes)
La transmission du code d'autorisation (Authorization Code) devrait (SHOULD) se faire via un canal sécurisé pour garantir la confidentialité et l'authenticité du client.
Le serveur d'autorisation doit (MUST) garantir que le code d'autorisation n'est utilisé qu'une seule fois. Si un code d'autorisation est utilisé plus d'une fois, le serveur d'autorisation doit (MUST) refuser la demande et devrait (SHOULD), si possible, révoquer tous les jetons précédemment émis sur la base de ce code d'autorisation.
10.6. Manipulation de l'URI de redirection du code d'autorisation (Authorization Code Redirection URI Manipulation)
Si un attaquant intercepte un code d'autorisation, l'attaquant peut tenter de remplacer l'URI de redirection utilisé par le client par un URI contrôlé par l'attaquant.
Le serveur d'autorisation doit (MUST) prévenir cette attaque en exigeant l'enregistrement de l'URI de redirection et en validant l'URI de redirection lorsque le client échange le code d'autorisation.
10.7. Informations d'identification du mot de passe du propriétaire de ressource (Resource Owner Password Credentials)
Le type d'autorisation par informations d'identification du mot de passe du propriétaire de ressource est souvent utilisé pour des raisons héritées ou de migration. Ce type d'autorisation ne devrait (SHOULD) être utilisé que lorsqu'il existe une relation de confiance élevée entre le propriétaire de ressource et le client.
10.8. Confidentialité des demandes (Request Confidentiality)
Les jetons d'accès, les jetons de rafraîchissement, les mots de passe du propriétaire de ressource et les informations d'identification du client ne doivent pas (MUST NOT) être transmis sans confidentialité. Il est recommandé (RECOMMENDED) d'utiliser TLS [RFC5246] version 1.2 ou ultérieure.
10.9. Garantie de l'authenticité des points de terminaison (Ensuring Endpoint Authenticity)
L'authentification du serveur TLS (définie dans RFC5246) devrait (SHOULD) être utilisée pour vérifier l'identité des points de terminaison avec lesquels le propriétaire de ressource et le client communiquent.
10.10. Attaques de devinette des informations d'identification (Credentials-Guessing Attacks)
Le serveur d'autorisation doit (MUST) implémenter des protections contre les attaques par force brute pour protéger le serveur d'autorisation lui-même et ses clients contre les attaques de devinette des informations d'identification.
10.11. Attaques de phishing (Phishing Attacks)
L'utilisation extensive de la redirection dans la conception du protocole OAuth crée des opportunités pour les attaquants d'exploiter le flux du protocole OAuth pour lancer des attaques de phishing.
Le serveur d'autorisation devrait (SHOULD) utiliser des mécanismes d'authentification conçus pour permettre au propriétaire de ressource de vérifier visuellement l'entité auprès de laquelle il s'authentifie.
10.12. Falsification de requête intersite (Cross-Site Request Forgery)
La falsification de requête intersite (CSRF) est une technique d'exploitation dans laquelle un attaquant amène l'agent utilisateur de la victime à envoyer des demandes non intentionnelles à l'insu de la victime.
Le client doit (MUST) utiliser le paramètre de demande « state » pour maintenir l'état entre sa demande de point de terminaison d'autorisation du client et le rappel ultérieur afin de se protéger contre les attaques CSRF.
10.13. Détournement de clic (Clickjacking)
Dans le détournement de clic, un attaquant enregistre un site cible fourni par un serveur légitime dans un iframe et le place au-dessus de l'iframe en tant que couche transparente.
Le serveur d'autorisation devrait (SHOULD) utiliser le champ d'en-tête X-Frame-Options pour prévenir les attaques de détournement de clic.
10.14. Injection de code et validation des entrées (Code Injection and Input Validation)
Toutes les valeurs d'entrée reçues par le serveur d'autorisation, le client et le serveur de ressources doivent (MUST) être validées pour éviter les attaques par injection.
10.15. Redirecteurs ouverts (Open Redirectors)
Le serveur d'autorisation, le point de terminaison d'autorisation et le point de terminaison de redirection du client ne doivent pas (MUST NOT) être conçus pour agir comme des redirecteurs ouverts.
10.16. Utilisation abusive du jeton d'accès pour usurper l'identité du propriétaire de ressource (Misuse of Access Token)
Dans le flux d'autorisation implicite, un attaquant peut utiliser un jeton d'accès intercepté pour usurper l'identité d'un propriétaire de ressource en usurpant l'identité d'un autre client.
Les développeurs de clients devraient (SHOULD) prendre des mesures pour s'assurer que les jetons d'accès ne sont utilisés que par le serveur de ressources prévu.