Flux de code d'autorisation OAuth 2.0 avec PKCE pour les clients publics

Ce que c'est

Dans l'octroi de code d'autorisation, le navigateur est redirigé vers le serveur d'autorisation, l'utilisateur consent, et le serveur redirige en retour avec un code de courte durée de vie, que le client échange contre des jetons au point de terminaison de jeton. Un client confidentiel authentifie cet échange avec son secret client ; un client public n'en a pas, de sorte qu'un code volé pourrait être échangé par n'importe qui. La RFC 7636 (citée) comble cette faille : le client génère un code_verifier, une chaîne aléatoire de 43 à 128 caractères non réservés, envoie code_challenge = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) avec code_challenge_method=S256 dans la requête d'autorisation, et envoie le code_verifier en clair avec le code au point de terminaison de jeton. Le serveur recalcule le hachage et refuse en cas de désaccord. La RFC indique qu'un client capable d'utiliser S256 doit le faire ; la méthode plain n'existe que pour les clients contraints.

Pourquoi c'est important

La RFC 8252 (citée) impose aux clients d'applications natives publiques de mettre en œuvre PKCE et aux serveurs d'autorisation de le prendre en charge, et demande aux applications natives d'utiliser le navigateur système plutôt qu'une vue web intégrée. La RFC 9700 (citée), les meilleures pratiques actuelles de sécurité OAuth, étend cette exigence : les clients publics doivent utiliser PKCE, il est recommandé aux clients confidentiels de le faire, les clients ne devraient pas utiliser l'octroi implicite (les jetons dans le fragment d'URL fuient via l'historique et les référents), les jetons de rafraîchissement des clients publics doivent être liés à l'émetteur (sender-constrained) ou soumis à rotation, et les URI de redirection doivent être comparés par correspondance exacte de chaîne (le port faisant exception pour localhost sur les applications natives). PKCE protège aussi contre l'injection de code d'autorisation, où un attaquant introduit dans la session de la victime un code obtenu ailleurs.

Comment l'appliquer

• Générer le vérificateur avec une source aléatoire cryptographiquement sûre à chaque requête d'autorisation ; le stocker avec la valeur state dans un emplacement lié à l'agent utilisateur (stockage de session pour une application navigateur, mémoire de processus pour une application en ligne de commande).
• Enregistrer des URI de redirection exactes. Pour une application native, en ligne de commande ou de bureau, la RFC 8252 décrit trois moyens de recevoir la réponse : un schéma d'URI à usage privé, une URI https revendiquée, ou une redirection en boucle locale (http://127.0.0.1:<port>/).
• Vérifier state au retour, échanger le code une seule fois, et supprimer le vérificateur.
• Demander un scope minimal, garder les jetons d'accès de courte durée de vie et utiliser la rotation des jetons de rafraîchissement, afin qu'un jeton de rafraîchissement divulgué soit détecté lors de sa réutilisation.
• Utiliser une bibliothèque cliente maintenue ; le flux comporte plus de cas particuliers (confusion entre clients, dégradation de code_challenge_method) qu'il n'en tient dans du code écrit à la main.

Pièges

Envoyer code_challenge mais laisser le serveur accepter des requêtes de jeton sans vérificateur (une dégradation que décrit le document de meilleures pratiques). Réutiliser un même vérificateur pour plusieurs requêtes. Stocker les jetons de rafraîchissement dans le localStorage d'une page qui exécute aussi des scripts tiers. Traiter un jeton d'accès comme une preuve d'identité ; c'est le rôle des jetons d'identité OpenID Connect.

Applications monopages : préférer un backend pour frontend

Une application dans le navigateur dotée de son propre serveur n'a pas à être un client public. La RFC 10017 (BCP 212, « OAuth 2.0 for Browser-Based Applications ») décrit l'architecture backend-pour-frontend, dans laquelle un petit backend exécute le flux de code d'autorisation en tant que client confidentiel (toujours avec PKCE), conserve les jetons d'accès et de rafraîchissement côté serveur et ne donne au navigateur qu'un cookie de session de même site (same-site) ; le document de meilleures pratiques la recommande fortement pour les applications professionnelles, les applications sensibles et celles qui traitent des données personnelles, car un script injecté dans la page peut sinon utiliser ou exfiltrer n'importe quel jeton détenu par le navigateur. N'utiliser le flux dans le navigateur décrit ci-dessus que lorsqu'aucun backend ne peut détenir les jetons, et alors les garder en mémoire plutôt que dans le stockage web.