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 lignes directrices axées sur les trois profils de clients décrits à la Section 2.1 : application Web, application fondée sur un agent utilisateur et application native.

Un modèle et une analyse de sécurité OAuth complets, ainsi que le contexte de conception du protocole, sont fournis par [OAuth-THREATMODEL].

10.1. Authentification du client (Client Authentication)

Le serveur d'autorisation établit des informations d'identification de client avec les clients de type application Web aux fins de l'authentification du client. Il est encouragé à envisager des moyens d'authentification du client plus forts qu'un mot de passe client. Les clients de type application Web doivent garantir la confidentialité des mots de passe client et des autres informations d'identification de client (MUST).

Le serveur d'autorisation ne doit pas émettre de mots de passe client ni d'autres informations d'identification de client aux clients de type application native ou application fondée sur un agent utilisateur aux fins de l'authentification du client (MUST NOT). Il peut émettre un mot de passe client ou d'autres informations d'identification pour une installation particulière d'un client d'application native sur un appareil particulier (MAY).

Lorsque l'authentification du client n'est pas possible, le serveur d'autorisation devrait 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 de confirmer l'identité (SHOULD). Une URI de redirection valide ne suffit pas à vérifier l'identité du client lors de la demande d'autorisation au propriétaire de ressource, mais elle peut empêcher la livraison d'informations d'identification à un client contrefait après l'obtention de cette autorisation.

Le serveur d'autorisation doit tenir compte des implications de sécurité liées aux interactions avec des clients non authentifiés et prendre des mesures pour limiter l'exposition potentielle des autres informations d'identification, par exemple les jetons de rafraîchissement, émises à ces clients.

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 n'est pas en mesure, de conserver ses informations d'identification de client confidentielles.

Le serveur d'autorisation doit authentifier le client chaque fois que possible (MUST). S'il ne peut pas authentifier le client en raison de la nature de celui-ci, le serveur d'autorisation doit exiger l'enregistrement de toute URI de redirection utilisée pour recevoir des réponses d'autorisation (MUST) et devrait utiliser d'autres moyens pour protéger les propriétaires de ressource de tels clients potentiellement malveillants (SHOULD). Par exemple, il peut faire intervenir le propriétaire de ressource pour aider à identifier le client et son origine.

Le serveur d'autorisation devrait imposer une authentification explicite du propriétaire de ressource et fournir à celui-ci des informations sur le client ainsi que sur la portée et la durée de l'autorisation demandée (SHOULD). Il appartient au propriétaire de ressource d'examiner ces informations dans le contexte du client courant et d'autoriser ou de refuser la demande.

Le serveur d'autorisation ne devrait pas traiter automatiquement des demandes d'autorisation répétées, sans interaction active du propriétaire de ressource, s'il n'authentifie pas le client ou ne s'appuie pas sur d'autres mesures garantissant que la demande répétée provient du client initial et non d'un usurpateur (SHOULD NOT).

10.3. Jetons d'accès (Access Tokens)

Les informations d'identification de jeton d'accès, ainsi que tout attribut confidentiel du jeton d'accès, doivent rester confidentiels en transit et au repos (MUST). Elles ne doivent être partagées qu'entre le serveur d'autorisation, les serveurs de ressources pour lesquels le jeton est valide et le client auquel le jeton a été émis. Les informations d'identification de jeton d'accès doivent être transmises uniquement au moyen de TLS comme décrit à la Section 1.6, avec l'authentification du serveur définie par [RFC2818] (MUST).

Lorsque le type d'autorisation implicite est utilisé, le jeton d'accès est transmis dans le fragment d'URI, ce qui peut l'exposer à des parties non autorisées.

Le serveur d'autorisation doit garantir que des parties non autorisées ne peuvent pas générer, modifier ou deviner des jetons d'accès de manière à produire des jetons valides (MUST).

Le client devrait demander des jetons d'accès avec la portée minimale nécessaire (SHOULD). Le serveur d'autorisation devrait tenir compte de l'identité du client lorsqu'il choisit comment satisfaire la portée demandée (SHOULD) et peut émettre un jeton d'accès avec moins de droits que ceux demandés (MAY).

Cette spécification ne fournit aucun moyen au serveur de ressources de s'assurer qu'un jeton d'accès qui lui est présenté par un client donné a été émis à ce client par le serveur d'autorisation.

10.4. Jetons de rafraîchissement (Refresh Tokens)

Les serveurs d'autorisation peuvent émettre des jetons de rafraîchissement aux clients de type application Web et application native (MAY).

Les jetons de rafraîchissement doivent rester confidentiels en transit et au repos (MUST), et ne doivent être partagés qu'entre le serveur d'autorisation et le client auquel ils ont été émis. Le serveur d'autorisation doit maintenir l'association entre un jeton de rafraîchissement et le client auquel il a été émis (MUST). Les jetons de rafraîchissement doivent être transmis uniquement au moyen de TLS comme décrit à la Section 1.6, avec l'authentification du serveur définie par [RFC2818] (MUST).

Le serveur d'autorisation doit vérifier l'association entre le jeton de rafraîchissement et l'identité du client chaque fois que l'identité du client peut être authentifiée (MUST). Lorsque l'authentification du client n'est pas possible, il devrait déployer d'autres moyens pour détecter l'abus de jetons de rafraîchissement (SHOULD).

Par exemple, le serveur d'autorisation peut employer une rotation des jetons de rafraîchissement, dans laquelle un nouveau jeton de rafraîchissement est émis avec chaque réponse de rafraîchissement de jeton d'accès. Le jeton précédent est invalidé mais conservé par le serveur d'autorisation. Si un jeton de rafraîchissement est compromis puis utilisé à la fois par l'attaquant et par le client légitime, l'un d'eux présentera un jeton invalidé, ce qui informera le serveur d'autorisation de la compromission.

Le serveur d'autorisation doit garantir que des parties non autorisées ne peuvent pas générer, modifier ou deviner des jetons de rafraîchissement valides (MUST).

10.5. Codes d'autorisation (Authorization Codes)

La transmission des codes d'autorisation devrait se faire sur un canal sécurisé (SHOULD), et le client devrait exiger l'utilisation de TLS avec son URI de redirection si cette URI identifie une ressource réseau (SHOULD). Comme les codes d'autorisation sont transmis par des redirections de l'agent utilisateur, ils peuvent être divulgués par l'historique de l'agent utilisateur et par les en-têtes HTTP Referer.

Les codes d'autorisation fonctionnent comme des informations d'identification bearer en clair, utilisées pour vérifier que le propriétaire de ressource ayant accordé l'autorisation auprès du serveur d'autorisation est le même que celui qui revient au client pour terminer le processus. Par conséquent, si le client s'appuie sur le code d'autorisation pour sa propre authentification du propriétaire de ressource, son point de terminaison de redirection doit exiger TLS (MUST).

Les codes d'autorisation doivent être de courte durée et à usage unique (MUST). Si le serveur d'autorisation observe plusieurs tentatives d'échange d'un même code d'autorisation contre un jeton d'accès, il devrait tenter de révoquer tous les jetons d'accès déjà accordés sur la base de ce code compromis (SHOULD).

Si le client peut être authentifié, le serveur d'autorisation doit authentifier le client et garantir que le code d'autorisation a été émis au même client (MUST).

10.6. Manipulation de l'URI de redirection du code d'autorisation

Lorsqu'il demande une autorisation au moyen du type d'autorisation par code, le client peut spécifier une URI de redirection au moyen du paramètre "redirect_uri". Si un attaquant peut manipuler cette valeur, il peut amener le serveur d'autorisation à rediriger l'agent utilisateur du propriétaire de ressource vers une URI sous son contrôle avec le code d'autorisation.

Un attaquant peut créer un compte chez un client légitime et lancer le flux d'autorisation. Lorsque son agent utilisateur est envoyé au serveur d'autorisation pour accorder l'accès, il capture l'URI d'autorisation fournie par le client légitime et remplace l'URI de redirection du client par une URI sous son contrôle. Il trompe ensuite la victime pour qu'elle suive le lien manipulé et autorise l'accès au client légitime.

Arrivée au serveur d'autorisation, la victime voit une demande normale et valide au nom d'un client légitime et de confiance, et l'autorise. Elle est ensuite redirigée vers un point de terminaison contrôlé par l'attaquant avec le code d'autorisation. L'attaquant termine le flux en envoyant ce code au client en utilisant l'URI de redirection originale fournie par le client. Le client échange le code contre un jeton d'accès et le lie au compte client de l'attaquant, qui peut alors accéder aux ressources protégées autorisées par la victime.

Pour prévenir cette attaque, le serveur d'autorisation doit garantir que l'URI de redirection utilisée pour obtenir le code d'autorisation est identique à celle fournie lors de l'échange du code contre un jeton d'accès (MUST). Il doit exiger l'enregistrement des URI de redirection pour les clients publics (MUST) et devrait l'exiger pour les clients confidentiels (SHOULD). Si une URI de redirection est fournie dans la demande, le serveur d'autorisation doit la valider par rapport à la valeur enregistrée (MUST).

10.7. Informations d'identification par mot de passe du propriétaire de ressource

Le type d'autorisation par informations d'identification du propriétaire de ressource est souvent utilisé pour des raisons de compatibilité ou de migration. Il réduit le risque global lié au stockage des noms d'utilisateur et mots de passe par le client, mais n'élimine pas la nécessité d'exposer au client des informations d'identification très privilégiées.

Ce type d'autorisation présente un risque plus élevé que les autres, car il maintient le modèle anti-pattern de mot de passe que le protocole cherche à éviter. Le client pourrait abuser du mot de passe, ou celui-ci pourrait être divulgué involontairement à un attaquant, par exemple via des journaux ou d'autres enregistrements conservés par le client.

De plus, comme le propriétaire de ressource ne contrôle pas le processus d'autorisation après avoir remis ses informations d'identification au client, celui-ci peut obtenir des jetons d'accès avec une portée plus large que souhaité. Le serveur d'autorisation devrait tenir compte de la portée et de la durée de vie des jetons émis via ce type d'autorisation.

Le serveur d'autorisation et le client devraient réduire au minimum l'utilisation de ce type d'autorisation et utiliser d'autres types chaque fois que possible (SHOULD).

10.8. Confidentialité des demandes (Request Confidentiality)

Les jetons d'accès, jetons de rafraîchissement, mots de passe du propriétaire de ressource et informations d'identification du client ne doivent pas être transmis en clair (MUST NOT). Les codes d'autorisation ne devraient pas être transmis en clair (SHOULD NOT).

Les paramètres "state" et "scope" ne devraient pas contenir en clair des informations sensibles concernant le client ou le propriétaire de ressource, car ils peuvent être transmis sur des canaux non sûrs ou stockés de manière non sûre (SHOULD NOT).

10.9. Garantie de l'authenticité des points de terminaison

Pour prévenir les attaques de l'homme du milieu, le serveur d'autorisation doit exiger TLS avec authentification du serveur, telle que définie par [RFC2818], pour toute demande envoyée aux points de terminaison d'autorisation et de jeton (MUST). Le client doit valider le certificat TLS du serveur d'autorisation comme défini par [RFC6125] et conformément à ses exigences d'authentification de l'identité du serveur (MUST).

10.10. Attaques par devinette des informations d'identification

Le serveur d'autorisation doit empêcher les attaquants de deviner les jetons d'accès, codes d'autorisation, jetons de rafraîchissement, mots de passe du propriétaire de ressource et informations d'identification du client (MUST).

La probabilité qu'un attaquant devine des jetons générés, et d'autres informations d'identification qui ne sont pas destinées à être manipulées par les utilisateurs finaux, doit être inférieure ou égale à 2^(-128) (MUST) et devrait être inférieure ou égale à 2^(-160) (SHOULD).

Le serveur d'autorisation doit utiliser d'autres moyens pour protéger les informations d'identification destinées aux utilisateurs finaux (MUST).

10.11. Attaques de phishing

Le déploiement étendu de ce protocole et de protocoles similaires peut habituer les utilisateurs finaux à être redirigés vers des sites Web où il leur est demandé de saisir leurs mots de passe. Si les utilisateurs ne vérifient pas soigneusement l'authenticité de ces sites avant de saisir leurs informations d'identification, des attaquants peuvent exploiter cette pratique pour voler les mots de passe des propriétaires de ressource.

Les fournisseurs de services devraient chercher à informer les utilisateurs finaux des risques posés par le phishing et fournir des mécanismes qui leur permettent de confirmer facilement l'authenticité de leurs sites. Les développeurs de clients devraient considérer les implications de sécurité de la manière dont ils interagissent avec l'agent utilisateur, par exemple externe ou intégré, ainsi que la capacité de l'utilisateur final à vérifier l'authenticité du serveur d'autorisation.

Pour réduire le risque de phishing, les serveurs d'autorisation doivent exiger TLS sur chaque point de terminaison utilisé pour l'interaction avec l'utilisateur final (MUST).

10.12. Falsification de requête intersite (Cross-Site Request Forgery)

La falsification de requête intersite (CSRF) est une attaque dans laquelle un attaquant amène l'agent utilisateur d'une victime à suivre une URI malveillante, par exemple un lien, une image ou une redirection trompeuse, vers un serveur de confiance, habituellement sur la base d'un cookie de session valide.

Une attaque CSRF contre l'URI de redirection du client permet à un attaquant d'injecter son propre code d'autorisation ou jeton d'accès. Le client peut alors utiliser un jeton d'accès associé aux ressources protégées de l'attaquant plutôt qu'à celles de la victime, par exemple enregistrer les informations de compte bancaire de la victime dans une ressource protégée contrôlée par l'attaquant.

Le client doit mettre en oeuvre une protection CSRF pour son URI de redirection (MUST). Cela se fait généralement en exigeant que toute demande envoyée au point de terminaison de redirection contienne une valeur liant la demande à l'état authentifié de l'agent utilisateur, par exemple un hachage du cookie de session utilisé pour authentifier l'agent utilisateur. Le client devrait utiliser le paramètre de demande "state" pour transmettre cette valeur au serveur d'autorisation lorsqu'il effectue une demande d'autorisation (SHOULD).

Une fois l'autorisation obtenue de l'utilisateur final, le serveur d'autorisation redirige l'agent utilisateur vers le client avec la valeur de liaison requise dans le paramètre "state". Cette valeur permet au client de vérifier la validité de la demande en la comparant à l'état authentifié de l'agent utilisateur. La valeur utilisée pour la protection CSRF doit contenir une valeur non devinable, comme décrit à la Section 10.10 (MUST), et l'état authentifié de l'agent utilisateur, par exemple cookie de session ou stockage local HTML5, doit être conservé dans un emplacement accessible seulement au client et à l'agent utilisateur, c'est-à-dire protégé par la politique de même origine (MUST).

Une attaque CSRF contre le point de terminaison d'autorisation du serveur d'autorisation peut permettre à un attaquant d'obtenir l'autorisation de l'utilisateur final pour un client malveillant sans impliquer ni alerter l'utilisateur final.

Le serveur d'autorisation doit mettre en oeuvre une protection CSRF pour son point de terminaison d'autorisation et garantir qu'un client malveillant ne peut pas obtenir d'autorisation sans la connaissance et le consentement explicite du propriétaire de ressource (MUST).

10.13. Détournement de clic (Clickjacking)

Dans une attaque de détournement de clic, l'attaquant enregistre un client légitime puis construit un site malveillant qui charge la page Web du point de terminaison d'autorisation du serveur d'autorisation dans une iframe transparente, superposée à un ensemble de boutons factices soigneusement placés sous les boutons importants de la page d'autorisation. Lorsque l'utilisateur final clique sur un bouton visible trompeur, il clique en réalité sur un bouton invisible de la page d'autorisation, par exemple "Authorize". L'attaquant peut ainsi amener le propriétaire de ressource à accorder l'accès à son client sans que l'utilisateur final s'en rende compte.

Pour prévenir cette forme d'attaque, les applications natives devraient utiliser des navigateurs externes au lieu d'intégrer des navigateurs dans l'application lorsqu'elles demandent l'autorisation de l'utilisateur final (SHOULD). Dans la plupart des navigateurs récents, le serveur d'autorisation peut empêcher l'utilisation d'iframes au moyen de l'en-tête non standard "x-frame-options". Cet en-tête peut avoir les valeurs "deny" et "sameorigin", qui bloquent respectivement tout encadrement ou l'encadrement par des sites d'origine différente. Pour les navigateurs plus anciens, des techniques JavaScript de frame-busting peuvent être utilisées, mais elles peuvent ne pas être efficaces dans tous les navigateurs.

10.14. Injection de code et validation des entrées

Une attaque par injection de code se produit lorsqu'une entrée ou une variable externe est utilisée par une application sans nettoyage et provoque une modification de la logique de l'application. Cela peut permettre à l'attaquant d'accéder à l'appareil applicatif ou à ses données, de provoquer un déni de service ou d'introduire une large gamme d'effets malveillants.

Le serveur d'autorisation et le client doivent nettoyer, et valider lorsque c'est possible, toute valeur reçue, en particulier les valeurs des paramètres "state" et "redirect_uri" (MUST).

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 peuvent être mal configurés et fonctionner comme des redirecteurs ouverts. Un redirecteur ouvert est un point de terminaison qui utilise un paramètre pour rediriger automatiquement un agent utilisateur vers l'emplacement indiqué par la valeur de ce paramètre sans validation.

Les redirecteurs ouverts peuvent être utilisés dans des attaques de phishing, ou par un attaquant pour amener des utilisateurs finaux à visiter des sites malveillants en utilisant le composant authority d'une URI familière et de confiance. De plus, si le serveur d'autorisation permet au client de n'enregistrer qu'une partie de l'URI de redirection, un attaquant peut utiliser un redirecteur ouvert exploité par le client pour construire une URI de redirection qui passera la validation du serveur d'autorisation mais enverra le code d'autorisation ou le jeton d'accès à un point de terminaison sous le contrôle de l'attaquant.

10.16. Utilisation abusive d'un jeton d'accès pour usurper le propriétaire de ressource dans le flux implicite

Pour les clients publics utilisant les flux implicites, cette spécification ne fournit aucun moyen permettant au client de déterminer à quel client un jeton d'accès a été émis.

Un propriétaire de ressource peut déléguer volontairement l'accès à une ressource en accordant un jeton d'accès au client malveillant d'un attaquant, à cause du phishing ou d'un autre prétexte. Un attaquant peut aussi voler un jeton par un autre mécanisme, puis tenter d'usurper le propriétaire de ressource en fournissant ce jeton à un client public légitime.

Dans le flux implicite (response_type=token), l'attaquant peut facilement remplacer le jeton dans la réponse du serveur d'autorisation, en substituant au vrai jeton d'accès celui qui lui a été précédemment émis.

Les serveurs qui communiquent avec des applications natives et qui s'appuient sur un jeton d'accès transmis par le canal arrière pour identifier l'utilisateur du client peuvent être compromis de manière similaire si un attaquant crée une application compromise capable d'injecter des jetons d'accès volés arbitraires.

Tout client public qui suppose que seul le propriétaire de ressource peut lui présenter un jeton d'accès valide pour la ressource est vulnérable à ce type d'attaque.

Ce type d'attaque peut exposer à l'attaquant, c'est-à-dire au client malveillant, des informations sur le propriétaire de ressource auprès du client légitime. Il permet aussi à l'attaquant d'effectuer des opérations chez le client légitime avec les mêmes permissions que le propriétaire de ressource qui avait initialement accordé le jeton d'accès ou le code d'autorisation.

L'authentification des propriétaires de ressource auprès des clients sort du périmètre de cette spécification. Toute spécification qui utilise le processus d'autorisation comme une forme d'authentification déléguée de l'utilisateur final auprès du client, par exemple un service de connexion tiers, ne doit pas utiliser le flux implicite sans mécanismes de sécurité supplémentaires permettant au client de déterminer si le jeton d'accès a été émis pour son usage, par exemple une restriction d'audience du jeton d'accès (MUST NOT).