8. Security Considerations (Considérations de sécurité)
8.1. Protecting the Authorization Code (Protection du code d'autorisation)
Les options d'URI de redirection documentées dans la section 7 partagent l'avantage que seule une application native sur le même appareil ou le propre site web de l'application peut recevoir le code d'autorisation (Authorization Code), ce qui limite la surface d'attaque. Cependant, l'interception du code par une application native différente s'exécutant sur le même appareil peut être possible.
Une limitation de l'utilisation de schémas URI à usage privé (Private-Use URI Schemes) pour les URI de redirection est que plusieurs applications peuvent généralement enregistrer le même schéma, ce qui rend indéterminé quelle application recevra le code d'autorisation. La section 1 de PKCE [RFC7636] détaille comment cette limitation peut être utilisée pour exécuter une attaque d'interception de code.
Les URI de redirection basées sur l'IP de bouclage peuvent être susceptibles d'interception par d'autres applications accédant à la même interface de bouclage sur certains systèmes d'exploitation.
Les redirections de schéma "https" revendiquées par l'application sont moins susceptibles d'interception d'URI en raison de la présence de l'autorité URI, mais l'application reste un client public (Public Client) ; de plus, l'URI est envoyé en utilisant le gestionnaire de distribution URI du système d'exploitation avec des propriétés de sécurité inconnues.
Le protocole PKCE [RFC7636] a été créé spécifiquement pour atténuer cette attaque. Il s'agit d'une extension de preuve de possession (Proof-of-Possession Extension) à OAuth 2.0 qui protège le code d'autorisation contre toute utilisation s'il est intercepté. Pour fournir une protection, cette extension fait générer au client un vérificateur secret (Secret Verifier) ; il transmet un hachage de ce vérificateur dans la demande d'autorisation initiale et doit (MUST) présenter le vérificateur non haché lors de l'échange du code d'autorisation. Une application qui a intercepté le code d'autorisation ne serait pas en possession de ce secret, rendant le code inutile.
La section 6 exige (MUST) que les clients et les serveurs utilisent PKCE pour les clients d'applications natives publiques. Les serveurs d'autorisation (Authorization Servers) devraient (SHOULD) rejeter les demandes d'autorisation des applications natives qui n'utilisent pas PKCE en renvoyant un message d'erreur, tel que défini dans la section 4.4.1 de PKCE [RFC7636].
8.2. OAuth Implicit Grant Authorization Flow (Flux d'autorisation par octroi implicite OAuth)
Le flux d'autorisation par octroi implicite OAuth 2.0 (défini dans la section 4.2 d'OAuth 2.0 [RFC6749]) fonctionne généralement avec la pratique d'effectuer la demande d'autorisation dans le navigateur et de recevoir la réponse d'autorisation via une communication inter-applications basée sur URI. Cependant, comme le flux implicite ne peut pas être protégé par PKCE [RFC7636] (qui est requis dans la section 8.1), l'utilisation du flux implicite avec les applications natives n'est PAS RECOMMANDÉE (NOT RECOMMENDED).
Les jetons d'accès (Access Tokens) accordés via le flux implicite ne peuvent pas non plus être actualisés sans interaction de l'utilisateur, ce qui fait du flux d'octroi de code d'autorisation (Authorization Code Grant Flow) -- qui peut émettre des jetons d'actualisation (Refresh Tokens) -- l'option la plus pratique pour les autorisations d'applications natives qui nécessitent l'actualisation des jetons d'accès.
8.3. Loopback Redirect Considerations (Considérations sur les redirections de bouclage)
Les URI de redirection d'interface de bouclage utilisent le schéma "http" (c'est-à-dire sans Transport Layer Security (TLS)). Ceci est acceptable pour les URI de redirection d'interface de bouclage car la requête HTTP ne quitte jamais l'appareil.
Les clients devraient (should) ouvrir le port réseau uniquement lors du démarrage de la demande d'autorisation et le fermer une fois la réponse retournée.
Les clients devraient (should) écouter uniquement sur l'interface réseau de bouclage, afin d'éviter les interférences d'autres acteurs du réseau.
Bien que les URI de redirection utilisant localhost (c'est-à-dire, http://localhost:{port}/{path}) fonctionnent de manière similaire aux redirections IP de bouclage décrites dans la section 7.3, l'utilisation de localhost n'est PAS RECOMMANDÉE (NOT RECOMMENDED). Spécifier une URI de redirection avec le littéral IP de bouclage plutôt que localhost évite d'écouter par inadvertance sur des interfaces réseau autres que l'interface de bouclage. Elle est également moins susceptible aux pare-feu côté client et à la résolution de nom d'hôte mal configurée sur l'appareil de l'utilisateur.
8.4. Registration of Native App Clients (Enregistrement des clients d'applications natives)
Sauf lors de l'utilisation d'un mécanisme comme l'enregistrement dynamique de clients (Dynamic Client Registration) [RFC7591] pour provisionner des secrets par instance, les applications natives sont classées comme clients publics, tel que défini par la section 2.1 d'OAuth 2.0 [RFC6749] ; elles doivent (MUST) être enregistrées auprès du serveur d'autorisation en tant que tels. Les serveurs d'autorisation doivent (MUST) enregistrer le type de client dans les détails d'enregistrement du client afin d'identifier et de traiter les demandes en conséquence.
Les serveurs d'autorisation doivent (MUST) exiger que les clients enregistrent leur URI de redirection complète (y compris le composant de chemin) et rejeter les demandes d'autorisation qui spécifient une URI de redirection qui ne correspond pas exactement à celle qui a été enregistrée ; l'exception concerne les redirections de bouclage, où une correspondance exacte est requise sauf pour le composant de port URI.
Pour les redirections basées sur des schémas URI à usage privé, les serveurs d'autorisation devraient (SHOULD) appliquer l'exigence de la section 7.1 selon laquelle les clients utilisent des schémas basés sur des noms de domaine inversés. Au minimum, tout schéma URI à usage privé qui ne contient pas de caractère point (".") devrait (SHOULD) être rejeté.
En plus des propriétés résistantes aux collisions, exiger un schéma URI basé sur un nom de domaine sous le contrôle de l'application peut aider à prouver la propriété en cas de litige où deux applications revendiquent le même schéma URI à usage privé (où une application agit de manière malveillante). Par exemple, si deux applications revendiquaient "com.example.app", le propriétaire de "example.com" pourrait demander à l'opérateur de la boutique d'applications de supprimer l'application contrefaite. Une telle pétition est plus difficile à prouver si un schéma URI générique a été utilisé.
Les serveurs d'autorisation peuvent (MAY) demander l'inclusion d'autres informations spécifiques à la plateforme, telles que le nom du package ou du bundle de l'application, ou d'autres informations qui peuvent être utiles pour vérifier l'identité de l'application appelante sur les systèmes d'exploitation qui prennent en charge de telles fonctions.
8.5. Client Authentication (Authentification du client)
Les secrets qui sont inclus de manière statique dans le cadre d'une application distribuée à plusieurs utilisateurs ne doivent pas être traités comme des secrets confidentiels, car un utilisateur peut inspecter sa copie et apprendre le secret partagé. Pour cette raison, et celles énoncées dans la section 5.3.1 de [RFC6819], il n'est PAS RECOMMANDÉ (NOT RECOMMENDED) que les serveurs d'autorisation exigent l'authentification du client des clients d'applications natives publiques à l'aide d'un secret partagé, car cela sert peu de valeur au-delà de l'identification du client qui est déjà fournie par le paramètre de demande "client_id".
Les serveurs d'autorisation qui exigent toujours un secret partagé inclus de manière statique pour les clients d'applications natives doivent (MUST) traiter le client comme un client public (tel que défini par la section 2.1 d'OAuth 2.0 [RFC6749]), et ne pas accepter le secret comme preuve de l'identité du client. Sans mesures supplémentaires, ces clients sont sujets à l'usurpation de client (voir section 8.6).
8.6. Client Impersonation (Usurpation de client)
Comme indiqué dans la section 10.2 d'OAuth 2.0 [RFC6749], le serveur d'autorisation ne devrait PAS (SHOULD NOT) traiter automatiquement les demandes d'autorisation sans consentement ou interaction de l'utilisateur, sauf lorsque l'identité du client peut être assurée. Cela inclut le cas où l'utilisateur a précédemment approuvé une demande d'autorisation pour un ID client donné -- à moins que l'identité du client ne puisse être prouvée, la demande devrait (SHOULD) être traitée comme si aucune demande précédente n'avait été approuvée.
Des mesures telles que les redirections de schéma "https" revendiquées peuvent (MAY) être acceptées par les serveurs d'autorisation comme preuve d'identité. Certains systèmes d'exploitation peuvent offrir des fonctionnalités d'identité alternatives spécifiques à la plateforme qui peuvent (MAY) être acceptées, le cas échéant.
8.7. Fake External User-Agents (Faux agents utilisateurs externes)
L'application native qui initie la demande d'autorisation a un grand degré de contrôle sur l'interface utilisateur et peut potentiellement présenter un faux agent utilisateur externe (External User-Agent), c'est-à-dire un agent utilisateur intégré (Embedded User-Agent) conçu pour ressembler à un agent utilisateur externe.
Lorsque tous les bons acteurs utilisent des agents utilisateurs externes, l'avantage est qu'il est possible pour les experts en sécurité de détecter les mauvais acteurs, car quiconque simule un agent utilisateur externe est manifestement mauvais. D'autre part, si les bons et les mauvais acteurs utilisent tous des agents utilisateurs intégrés, les mauvais acteurs n'ont pas besoin de simuler quoi que ce soit, ce qui les rend plus difficiles à détecter. Une fois qu'une application malveillante est détectée, il peut être possible d'utiliser ces connaissances pour mettre sur liste noire la signature de l'application dans les logiciels d'analyse de logiciels malveillants, prendre des mesures de suppression (dans le cas d'applications distribuées par les boutiques d'applications) et d'autres mesures pour réduire l'impact et la propagation de l'application malveillante.
Les serveurs d'autorisation peuvent également se protéger directement contre les faux agents utilisateurs externes en exigeant un facteur d'authentification uniquement disponible pour les vrais agents utilisateurs externes.
Les utilisateurs qui sont particulièrement préoccupés par leur sécurité lors de l'utilisation d'onglets de navigateur intégrés à l'application peuvent également prendre la mesure supplémentaire d'ouvrir la demande dans le navigateur complet à partir de l'onglet de navigateur intégré à l'application et de terminer l'autorisation là-bas, car la plupart des implémentations du modèle d'onglet de navigateur intégré à l'application offrent une telle fonctionnalité.
8.8. Malicious External User-Agents (Agents utilisateurs externes malveillants)
Si une application malveillante est capable de se configurer comme gestionnaire par défaut des URI de schéma "https" dans le système d'exploitation, elle sera en mesure d'intercepter les demandes d'autorisation qui utilisent le navigateur par défaut et d'abuser de cette position de confiance à des fins malveillantes telles que le phishing de l'utilisateur.
Cette attaque n'est pas confinée à OAuth ; une application malveillante configurée de cette manière présenterait un risque général et continu pour l'utilisateur au-delà de l'utilisation d'OAuth par les applications natives. De nombreux systèmes d'exploitation atténuent ce problème en exigeant une action utilisateur explicite pour changer le gestionnaire par défaut des URI de schéma "http" et "https".
8.9. Cross-App Request Forgery Protections (Protections contre la falsification de demande inter-applications)
La section 5.3.5 de [RFC6819] recommande d'utiliser le paramètre "state" pour lier les demandes et les réponses du client afin de prévenir les attaques CSRF (Cross-Site Request Forgery).
Pour atténuer les attaques de type CSRF sur les canaux de communication inter-applications par URI (appelées "falsification de demande inter-applications"), il est de même recommandé (RECOMMENDED) que les applications natives incluent un nombre aléatoire sécurisé à haute entropie dans le paramètre "state" de la demande d'autorisation et rejettent toute réponse d'autorisation entrante sans valeur d'état correspondant à une demande d'autorisation sortante en attente.
8.10. Authorization Server Mix-Up Mitigation (Atténuation de la confusion de serveur d'autorisation)
Pour se protéger contre un serveur d'autorisation compromis ou malveillant attaquant un autre serveur d'autorisation utilisé par la même application, il est requis (REQUIRED) qu'une URI de redirection unique soit utilisée pour chaque serveur d'autorisation utilisé par l'application (par exemple, en variant le composant de chemin), et que les réponses d'autorisation soient rejetées si l'URI de redirection sur laquelle elles ont été reçues ne correspond pas à l'URI de redirection dans une demande d'autorisation sortante.
L'application native doit (MUST) stocker l'URI de redirection utilisée dans la demande d'autorisation avec les données de session d'autorisation (c'est-à-dire, avec "state" et d'autres données connexes) et doit (MUST) vérifier que l'URI sur laquelle la réponse d'autorisation a été reçue correspond exactement.
L'exigence de la section 8.4, en particulier que les serveurs d'autorisation rejettent les demandes avec des URI qui ne correspondent pas à ce qui a été enregistré, est également requise pour prévenir de telles attaques.
8.11. Non-Browser External User-Agents (Agents utilisateurs externes non-navigateurs)
Cette meilleure pratique recommande un type particulier d'agent utilisateur externe : le navigateur de l'utilisateur. D'autres modèles d'agents utilisateurs externes peuvent également être viables pour un OAuth sécurisé et utilisable. Ce document ne fait aucun commentaire sur ces modèles.
8.12. Embedded User-Agents (Agents utilisateurs intégrés)
La section 9 d'OAuth 2.0 [RFC6749] documente deux approches pour que les applications natives interagissent avec le point de terminaison d'autorisation. Cette meilleure pratique actuelle exige (MUST NOT) que les applications natives n'utilisent pas d'agents utilisateurs intégrés pour effectuer des demandes d'autorisation et permet que les points de terminaison d'autorisation puissent (MAY) prendre des mesures pour détecter et bloquer les demandes d'autorisation dans les agents utilisateurs intégrés. Les considérations de sécurité pour ces exigences sont détaillées ici.
Les agents utilisateurs intégrés sont une méthode alternative pour autoriser les applications natives. Ces agents utilisateurs intégrés sont, par définition, dangereux pour une utilisation par des tiers au serveur d'autorisation, car l'application qui héberge l'agent utilisateur intégré peut accéder aux informations d'authentification complètes de l'utilisateur, et pas seulement à l'octroi d'autorisation OAuth qui était destiné à l'application.
Dans les implémentations typiques basées sur une vue web d'agents utilisateurs intégrés, l'application hôte peut enregistrer chaque frappe de touche entrée dans le formulaire de connexion pour capturer les noms d'utilisateur et les mots de passe, soumettre automatiquement des formulaires pour contourner le consentement de l'utilisateur, et copier les cookies de session et les utiliser pour effectuer des actions authentifiées en tant qu'utilisateur.
Même lorsqu'ils sont utilisés par des applications de confiance appartenant à la même partie que le serveur d'autorisation, les agents utilisateurs intégrés violent le principe du moindre privilège en ayant accès à des informations d'identification plus puissantes que nécessaire, augmentant potentiellement la surface d'attaque.
Encourager les utilisateurs à entrer des informations d'identification dans un agent utilisateur intégré sans la barre d'adresse habituelle et les fonctionnalités de validation de certificat visibles que possèdent les navigateurs rend impossible pour l'utilisateur de savoir s'il se connecte au site légitime ; même lorsque c'est le cas, cela leur apprend qu'il est acceptable d'entrer des informations d'identification sans valider d'abord le site.
Outre les préoccupations de sécurité, les agents utilisateurs intégrés ne partagent pas l'état d'authentification avec d'autres applications ou le navigateur, obligeant l'utilisateur à se connecter pour chaque demande d'autorisation, ce qui est souvent considéré comme une expérience utilisateur inférieure.