La RFC 9700, publiée en janvier 2025 sous la référence BCP 240, distingue les mesures de durcissement OAuth 2.0 qui sont des MUST de celles qui ne sont que des SHOULD. Une redirect URI avec wildcard oubliée dans la console d'un fournisseur d'identité est typiquement le genre de réglage qu'elle exclut, et un code client irréprochable n'y change rien. La RFC met à jour les RFC 6749, RFC 6750 et RFC 6819, et avertit que son application peut casser l'interopérabilité avec des écosystèmes plus anciens. Elle recommande malgré tout de migrer dès que possible.
Les exigences, par niveau
| Réglage | Niveau | Position de la RFC 9700 |
|---|---|---|
| Comparaison des redirect URI | MUST | Les serveurs d'autorisation utilisent une comparaison exacte de chaînes |
| Open redirectors | MUST NOT | Les clients et les serveurs d'autorisation ne doivent pas en exposer |
| Protection CSRF | MUST | Les clients protègent le endpoint de redirection : PKCE, nonce ou un state à usage unique |
| Défense contre le mix-up, plusieurs serveurs d'autorisation | REQUIRED | Paramètre iss ou valeur iss équivalente ; URI de redirection distinctes en solution de repli |
| PKCE, clients publics | MUST | Obligatoire pour l'authorization code grant |
| PKCE, clients confidentiels | RECOMMENDED | Les clients OpenID Connect PEUVENT utiliser nonce à la place, avec des précautions supplémentaires |
Application du code_verifier | MUST | Contrôlé au token endpoint dès qu'un code_challenge valide a été envoyé |
| Méthode du challenge PKCE | SHOULD | Une méthode qui n'expose pas le verifier ; actuellement seulement S256 |
Implicit grant (response_type=token) | SHOULD NOT | Utiliser code ou un autre type qui émet les tokens au token endpoint |
| Access tokens sender-constrained | SHOULD | Mutual TLS ou DPoP |
| Refresh tokens, clients publics | MUST | Sender-constrained ou soumis à rotation |
Redirect URI : correspondance exacte et pas d'open redirectors
Lorsque le serveur d'autorisation compare le redirect_uri d'une requête aux valeurs enregistrées, il doit utiliser une comparaison exacte de chaînes. La seule exception concerne le numéro de port dans les URI de redirection localhost des applications natives. Les wildcards, les correspondances par préfixe et les enregistrements du type « n'importe quel chemin sous cet hôte » échouent tous à cette règle.
La liste enregistrée compte aussi, car chaque entrée est une cible autorisée pour les authorization codes. Supprimez les entrées obsolètes, en particulier les hôtes que vous ne contrôlez plus, comme un domaine de staging désaffecté qu'une autre personne pourrait récupérer.
Les open redirectors constituent l'autre moitié du problème. Un endpoint qui renvoie le navigateur vers une URI arbitraire issue d'un paramètre de requête peut faire fuiter des authorization codes et des access tokens, et la RFC précise que ni les clients ni les serveurs d'autorisation ne doivent en exposer. L'exemple de l'OWASP http://example.com/example.php?url=http://malicious.example.com illustre le problème : l'utilisateur voit l'hôte de confiance et ne remarque pas la redirection.
L'aide-mémoire de l'OWASP sur les redirections non validées donne la solution. La meilleure consiste à associer côté serveur un identifiant court à une cible, au lieu d'accepter une URL. Si vous devez en accepter une, analysez-la avec un parseur maintenu et comparez le schéma, l'hôte canonique et le port effectif à une allowlist explicite. Rejetez les userinfo, et ne vous appuyez jamais sur des préfixes ou suffixes bruts.
PKCE sur tous les clients, obligatoire pour les clients publics
Les clients publics doivent utiliser PKCE. Pour les clients confidentiels, il est recommandé, car il empêche aussi l'injection de code et, par effet de bord, le CSRF. Les clients OpenID Connect confidentiels peuvent utiliser nonce et la claim correspondante de l'ID Token à la place, mais uniquement avec les précautions de la section 4.5.3.2. Ce conseil vaut aussi pour les applications web, bien que PKCE ait été conçu pour les applications natives.
- La valeur du challenge doit changer à chaque transaction. Une valeur constante annule l'intérêt du mécanisme.
- Utilisez
S256. La RFC 9700 la présente comme la seule méthode actuelle qui n'expose pas le verifier dans la requête d'autorisation ; un attaquant capable de lire cette requête peut sinon contourner PKCE. La RFC 7636 précise queplainne protège que contre un attaquant qui ne voit que les réponses. - Le verifier est une chaîne aléatoire de 43 à 128 caractères issus du jeu de caractères non réservés. La RFC 7636 recommande 32 octets aléatoires encodés en base64url, ce qui donne 43 caractères.
Le serveur doit aussi bloquer le downgrade : une requête de token contenant un code_verifier n'est acceptée que si la requête d'autorisation comportait un code_challenge. Publier code_challenge_methods_supported dans les métadonnées du serveur permet aux clients de détecter la prise en charge de PKCE.
Implicit grant, CSRF et mix-up
Les clients ne devraient pas utiliser response_type=token ni aucun type de réponse qui renvoie des access tokens dans la réponse d'autorisation. La RFC 9700 les juge vulnérables à la fuite et au rejeu de tokens, et note qu'il n'existe aucune méthode standardisée pour appliquer le sender-constraining à un token émis de cette façon. Utilisez code, ou un type qui émet les tokens au token endpoint, comme code id_token.
La protection contre le CSRF sur le endpoint de redirection exige PKCE (si le client a confirmé que le serveur le prend en charge), le nonce dans les flux OpenID Connect, ou une valeur state à usage unique liée au user agent. Si votre client dialogue avec plusieurs serveurs d'autorisation, utilisez le paramètre iss de la RFC 9207 ou une valeur iss équivalente, comme la claim de l'ID Token.
Tokens : appliquer le sender-constraining dès que possible
Les serveurs d'autorisation et les serveurs de ressources devraient appliquer le sender-constraining aux access tokens avec mutual TLS (RFC 8705) ou DPoP (RFC 9449), afin qu'un token volé soit inutilisable sans le secret correspondant. Les refresh tokens des clients publics doivent être sender-constrained ou soumis à rotation, comme le décrit la section 4.14 de la RFC.
Par où commencer
- Listez toutes les redirect URI enregistrées pour chaque client. Supprimez les wildcards, les chemins partiels et les hôtes que vous ne contrôlez plus. Puis, dans une requête d'autorisation réelle, ajoutez un chemin ou changez un sous-domaine : le serveur doit la rejeter.
- Recherchez les paramètres de redirection tels que
url,nextoureturnUrlcôté client et côté serveur d'autorisation. Remplacez les URL libres par une table de correspondance d'identifiants côté serveur ou par une allowlist d'URL analysées. - Recherchez
response_type=tokendans le code client et dans la configuration des serveurs. Faites migrer ces clients vers l'authorization code flow avec PKCE enS256. - Testez PKCE directement. Envoyez une requête d'autorisation sans
code_challenge, puis échangez le code avec uncode_verifier. Échangez ensuite un code protégé par PKCE sans le verifier. Les deux tentatives doivent échouer au token endpoint ; si un token figure dans la réponse, le serveur échoue au test. - Testez
state: rejouez une valeur déjà utilisée, puis soumettez-en une issue d'une autre session de navigateur ; le client doit rejeter les deux. Si votre fournisseur renvoieiss, altérez-le et vérifiez que le client rejette la réponse. Inspectez les claims des ID Tokens avec notre outil JWT et, si vous souhaitez un regard extérieur, un test d'intrusion peut couvrir ces flux. - Pour les clients publics, choisissez entre sender-constraining et rotation. Si vous optez pour la rotation, présentez deux fois un refresh token déjà utilisé lors d'un test et observez la réaction du serveur. Retrouvez cette tentative dans les logs du serveur d'autorisation, car le nom des événements varie selon les produits, et déclenchez une alerte dessus.
