Pourquoi PKCE n'est-il pas encouragé pour les applications à page unique?
De nombreux services recommandent encore aujourd'hui le flux implicite pour un échange de jetons OpenID Connect/Oauth2 lors du développement d'applications à page unique. (Voir Okta - recommande désormais PKCE avec repli implicite, Google , Auth )
Certains conseils plus récents là-bas indiquent l'utilisation du flux de code d'autorisation sans client_secret dans l'étape d'échange de jetons, ce qui, je peux en convenir, est logique pour les raisons citées dans l'article (par exemple, les jetons ne vivent pas dans le navigateur histoire, journaux Web, etc.). Pourquoi ce concept ne va-t-il pas plus loin avec PKCE? Au lieu d'omettre complètement le client_secret, pourquoi ne pas en utiliser un dynamique car il est recommandé pour les applications natives? Les SPA et les applications natives sont tous deux considérés comme des "clients publics" où un secret ne peut pas être conservé en toute sécurité, mais seules les applications natives obtiennent la recommandation PKCE tandis que les SPA semblent être conservés dans le passé.
Je comprends que les implications de sécurité que PKCE essaie de résoudre ne sont pas directement liées à un contexte de navigateur uniquement, mais cela ne pourrait-il pas être considéré comme un mécanisme de défense en profondeur et utilisé de toute façon? Je sais par expérience que Google ne vous permettra pas de générer des informations d'identification d'application Web et d'essayer d'utiliser autre chose qu'implicite pour un SPA (voir ce problème ), le flux de code d'autorisation attendra un client_secret et l'échange PKCE ne fonctionne que si vous choisissez un type d'informations d'identification d'application native, mais vous ne pouvez pas spécifier https redirect_uri pour votre application.
D'autres fournisseurs autorisent PKCE avec le flux de code d'autorisation dans un contexte Web, mais ce n'est pas recommandé par eux. Ai-je tort de vouloir cela et de l'utiliser? Il semble assez trivial d'ajouter les étapes supplémentaires de génération et de contournement des défis de code avec les API Web Crypto disponibles ( ciblage nouveaux navigateurs et calage selon les besoins).
@catanman fait d'excellents points concernant les considérations techniques autour de PKCE dans les SPA, mais tout récemment le groupe de travail IETF Oauth a publié un document sur les meilleures pratiques actuelles (28 décembre 2018 ) indiquant:
Remarque: bien que PKCE ait jusqu'à présent été recommandé comme mécanisme de protection des applications natives, ce conseil s'applique à toutes sortes de clients OAuth, y compris les applications Web.
Bien que toutes les autres réponses soient correctes, la dernière OAuth 2.0 for Browser-Based Apps Best Practices Doc (29 janvier 2019) indique que (c'est moi qui souligne):
Aperçu
Pour autoriser les utilisateurs dans une application basée sur un navigateur, le meilleur
la pratique actuelle consiste ào Utilisez le flux de code d'autorisation OAuth 2.0 avec l'extension PKCE
...
Aussi bien que
7.1. Lancement de la demande d'autorisation à partir d'une application basée sur un navigateur
Les applications basées sur un navigateur public DOIVENT implémenter la clé de preuve pour le code
Exchange (PKCE [RFC7636]) extension à OAuth, et autorisation
Les serveurs DOIVENT prendre en charge PKCE pour ces clients.L'extension PKCE empêche une attaque où le code d'autorisation est intercepté et échangé contre un jeton d'accès par un client malveillant, en fournissant au serveur d'autorisation un moyen de vérifier que la même instance client qui échange le code d'autorisation est la même que celle qui a initié le flux. .
Je suppose qu'il y a quelques avantages mineurs qui valent la peine de le faire en tant que défense en profondeur, même pour les applications basées sur un navigateur.
Les SPA ne bénéficieraient pas du PKCE. PKCE résout un problème différent de celui que vous décrivez.
Tout d'abord, pour les SPA , la meilleure pratique actuelle consiste toujours à utiliser le flux implicite , pas le flux de code d'autorisation. Avec le flux implicite, le jeton d'accès est inclus dans le fragment de hachage (#) de l'URI de redirection au lieu d'un composant de requête (?). Étant donné que le navigateur n'inclut jamais la partie fragment de hachage d'un URI lorsqu'il fait une demande, le jeton n'apparaît pas dans historique du navigateur, journaux Web ...
En ce qui concerne les applications natives , rfc8252 section 6 dit ce qui suit:
Les clients d'applications natives publiques DOIVENT implémenter la clé de preuve pour l'échange de code (PKCE RFC7636])
En passant, notez que l'exigence PKCE est pour les clients natifs public. Vous vous demandez peut-être comment une application native peut pas être publique. La réponse est dans section 8.4 :
Sauf lors de l'utilisation d'un mécanisme tel que Dynamic Client Registration [RFC7591] pour provisionner des secrets par instance, les applications natives sont classées comme clients publics
Je ne sais pas exactement comment faire référence à ces clients car je n'ai jamais vu client natif confidentiel mentionné nulle part. Peut-être client natif non public fonctionne :)
Pour répondre à votre question: pourquoi le flux de code d'autorisation avec PKCE est-il requis pour les applications natives publiques et non pour les SPA?
La logique est la suivante:
- L'un des principaux objectifs d'OAuth2 est d'empêcher l'exposition des informations d'identification de l'utilisateur aux clients.
- Pour que les applications natives satisfassent à cette exigence, l'utilisateur ne doit pas entrer les informations d'identification partout où l'application native a accès. Les écrans de connexion natifs et les vues Web doivent donc être évités.
- La solution consiste pour les applications natives à lancer un agent utilisateur externe (voir rfc8252 annexe B ) où l'utilisateur s'authentifiera auprès du serveur d'autorisation et autorisera l'application. Les applications natives n'ont pas accès à l'agent utilisateur externe, les informations d'identification de l'utilisateur sont donc sécurisées.
- Cependant, une nouvelle complication a été introduite qui n'existait pas avec les SPA: l'agent utilisateur externe doit maintenant communiquer la réponse du serveur d'autorisation à l'application native? La réponse est la communication inter-applications (voir section 5 et section 7 )
- Malheureusement, plusieurs types de communication inter-applications peuvent être interceptés par des applications tierces malveillantes! Avec le flux implicite, cela signifie que le jeton d'accès pourrait être volé par une application malveillante, ce qui serait une très mauvaise chose. C'est l'une des principales raisons pour lesquelles le flux implicite n'est pas utilisé pour les applications natives.
- Mais même si le flux de code d'autorisation est utilisé à la place, l'application tierce malveillante peut toujours intercepter le code d'autorisation et l'utiliser pour obtenir un jeton d'accès car il n'y a pas de secret client. Il semble donc inutile d'utiliser le flux de code d'autorisation au lieu du flux implicite pour les applications natives publiques.
- C'est là qu'intervient PKCE. PKCE fait en sorte que même si une application malveillante intercepte un code d'autorisation, elle ne pourra pas l'échanger contre un jeton d'accès. Ceci est accompli en exigeant que l'entité qui demande le jeton d'accès prouve que c'est la même entité qui a demandé le code d'autorisation en premier lieu.
J'espère que vous comprenez maintenant pourquoi:
- Les SPA ne bénéficieraient pas du tout de PKCE car avec les SPA, tout se passe dans le navigateur. PKCE n'est utile que lorsqu'il existe une communication inter-applications.
- Les applications natives publiques ne doivent pas utiliser le flux implicite car la communication inter-applications peut parfois être non sécurisée.
- Les applications natives publiques doivent utiliser le flux de code d'autorisation + PKCE
Voici un bon article de blog qui peut fournir plus d'informations: https://medium.com/@justinsecurity/mobile-apps-and-oauths-implicit-flow-68e72c6515a1