Attaques par rétrogradation PKCE : pourquoi OAuth 2.1 n'est plus optionnel 🔑📉

Dans le paysage en constante évolution de la cybersécurité, les protocoles que nous considérions autrefois “suffisamment sécurisés” sont démantelés par des vecteurs d’attaque modernes. Depuis plus d’une décennie, OAuth 2.0 (RFC 6749) servait de fondation pour l’autorisation web et mobile. Cependant, à partir de janvier 2026, l’industrie a atteint un point critique. Avec la stabilisation d’OAuth 2.1 et la publication de RFC 9700 (Meilleures Pratiques de Sécurité Actuelles), le flux d’autorisation “standard” sans PKCE (Proof Key for Code Exchange) n’est plus simplement “obsolète” — c’est une vulnérabilité.

Cet article explore la mécanique technique des attaques par rétrogradation PKCE, pourquoi se reposer sur des valeurs client_secret statiques dans les clients publics est une “théâtralisation de la sécurité”, et pourquoi migrer vers OAuth 2.1 est la seule façon de protéger vos utilisateurs contre des techniques sophistiquées de vol de tokens.

1. La fin d’OAuth 2.0 : qu’est-ce qu’OAuth 2.1 ?

OAuth 2.1 n’est pas un protocole entièrement nouveau. Il s’agit plutôt d’une consolidation de diverses extensions de sécurité et de “Meilleures Pratiques Actuelles” (BCPs) publiées depuis 2012. Il “nettoie” efficacement OAuth 2.0 en supprimant les fonctionnalités non sécurisées et en rendant obligatoires des mesures de sécurité autrefois optionnelles.

Principaux changements dans OAuth 2.1 :

PKCE est obligatoire : Chaque flux d’autorisation par code — que ce soit pour un serveur backend (client confidentiel) ou une application mobile/SPA (client public) — doit utiliser PKCE.

Le flux implicite supprimé : Le flux “Implication”, qui renvoie directement des tokens dans le fragment d’URL, est officiellement abandonné.

Suppression du ROPC : La concession “Resource Owner Password Credentials” (où l’application gère le mot de passe de l’utilisateur) est supprimée.

Correspondance exacte de l’URI de redirection : Les jokers dans les URI de redirection ne sont plus autorisés ; le serveur doit faire une correspondance bit-à-bit.

La transition vers OAuth 2.1 est motivée par une prise de conscience principale : les codes d’autorisation sont vulnérables à l’interception dans le “canal frontal”.

2. Anatomie d’une attaque d’interception

Pour comprendre pourquoi PKCE est nécessaire, il faut d’abord voir comment les attaquants volent les codes d’autorisation dans les applications mobiles et les applications monopage.

Applications mobiles & schémas d’URL personnalisés

Dans les environnements mobiles, les applications communiquent souvent via des schémas d’URL personnalisés (par ex., my-app://callback). Lorsqu’un utilisateur termine l’authentification dans un navigateur mobile, le serveur d’autorisation (AS) redirige l’utilisateur vers l’application en utilisant ce schéma.

La vulnérabilité : Sur de nombreux systèmes d’exploitation, plusieurs applications peuvent s’enregistrer pour le même schéma d’URL personnalisé. Si une application malveillante est installée sur l’appareil et s’enregistre pour my-app://, elle peut “gagner” la course et recevoir la redirection au lieu de l’application légitime. L’application malveillante obtient alors le code d’autorisation.

SPA et historique du navigateur

Dans les applications monopage (SPA), le code d’autorisation est livré via un paramètre d’URL dans le navigateur. Ce code peut fuir par :

• Historique du navigateur : Si un attaquant accède à l’appareil, il peut simplement consulter l’historique.
• En-têtes Referer : Si la SPA fait une requête à un script tiers (comme un tracker publicitaire) immédiatement après la redirection, l’URL contenant le code peut être envoyée dans l’en-tête Referer.
• Logs : Les serveurs proxy ou extensions de navigateur peuvent enregistrer l’URL complète.

3. Qu’est-ce que PKCE ? (La protection moderne)

PKCE (Proof Key for Code Exchange), défini dans RFC 7636, a été initialement conçu pour résoudre le problème du schéma d’URL personnalisé dans les applications mobiles. Il introduit trois nouveaux composants dans le flux :

• Code Verifier : Une chaîne aléatoire cryptographiquement générée par le client pour chaque requête.
• Code Challenge : Une version hachée du vérificateur (généralement en utilisant SHA-256).
• Code Challenge Method : L’algorithme utilisé (par ex., S256).

Fonctionnement de PKCE :

1. L’initiation : Le client génère un code_verifier, le hache pour créer un code_challenge, et envoie le défi au serveur d’autorisation.

2. Le code : Le AS délivre un code d’autorisation mais le “lier” au défi.

3. L’échange : Lors de l’échange du code contre un token, le client doit envoyer le code_verifier original, non haché. Le AS le hache et vérifie s’il correspond au code_challenge fourni à l’étape 1.

Pourquoi cela empêche le vol : Même si un attaquant vole le code d’autorisation, il ne possède pas le code_verifier (qui n’a jamais quitté le client). Sans le vérificateur, le code est inutile.

4. L’attaque par rétrogradation PKCE : le piège caché

Une attaque par rétrogradation PKCE se produit lorsque le serveur d’autorisation supporte PKCE mais ne l’applique pas à tous les clients.

Scénario d’attaque :

1. La configuration : Un attaquant se place au milieu (par ex., via une extension de navigateur compromise ou une application malveillante).

2. La modification : Lorsque le client légitime démarre un flux OAuth, il envoie une requête contenant un code_challenge.

3. La rétrogradation : L’attaquant intercepte la requête initiale et supprime les paramètres code_challenge et code_challenge_method avant que la requête n’atteigne le serveur d’autorisation.

4. L’erreur du serveur : Si le AS est configuré pour être “compatibilité arrière” avec OAuth 2.0, il voit une requête sans paramètres PKCE et suppose que le client est un “ancien” client. Il poursuit avec un flux standard, non PKCE.

5. Le vol : Le AS délivre un code. L’attaquant intercepte ce code via un schéma d’URL personnalisé ou l’historique du navigateur.

6. Le gain : Étant donné que le AS pense qu’il s’agit d’un flux sans PKCE, il ne demande pas de code_verifier lors de l’échange du token. L’attaquant échange le code volé contre un token d’accès valide.

La solution dans OAuth 2.1 : En rendant PKCE obligatoire, OAuth 2.1 exige que le serveur d’autorisation rejette toute requête d’autorisation sans code_challenge. Cela élimine totalement la voie de rétrogradation.

5. Pourquoi client_secret est une “théâtralisation de la sécurité”

De nombreux développeurs pensent que l’utilisation d’un client_secret les protège. Bien que cela soit vrai pour les Clients Confidentiels (serveurs où le secret est caché dans des variables d’environnement), c’est totalement faux pour les Clients Public (Mobile et SPA).

La fausse sécurité du SPA

Si vous mettez un client_secret dans une SPA basée sur JavaScript, il est public. N’importe qui peut ouvrir F12 dans Chrome, aller dans l’onglet “Sources” et le trouver.

La fausse sécurité mobile

Les applications mobiles sont souvent compilées, mais facilement décompilables. Des outils comme apktool ou Ghidra permettent aux attaquants d’extraire des chaînes statiques (comme des secrets) d’un binaire en quelques secondes.

Le problème des secrets statiques :

Un client_secret est une “preuve d’identité”, pas une “preuve de possession” pour une transaction spécifique. Si un secret est divulgué une fois, un attaquant peut se faire passer pour ce client indéfiniment. PKCE, en revanche, utilise un secret dynamique, unique à chaque transaction (le code_verifier). C’est pourquoi OAuth 2.1 privilégie PKCE plutôt que des secrets statiques pour la sécurité côté frontal.

6. Le vol de tokens à l’ère moderne : au-delà du code

Se fier aux flux hérités vous expose à des techniques modernes de vol de tokens qui contournent les défenses traditionnelles :

Injection de code d’autorisation : Les attaquants peuvent injecter un code volé dans leur propre session. PKCE (lorsqu’il est utilisé avec le paramètre iss ou un nonce) empêche cela en garantissant que le code appartient à la session spécifique du navigateur qui a lancé le flux.

Infostealers : Les malwares ciblant la mémoire du navigateur peuvent extraire des tokens. OAuth 2.1 encourage l’utilisation de tokens contraints par le destinataire (via DPoP - Demonstrating Proof-of-Possession), ce qui garantit qu’un token ne peut être utilisé que par l’appareil spécifique qui l’a demandé.

Abus de refresh tokens : Par le passé, les refresh tokens pour SPA étaient considérés comme dangereux. OAuth 2.1 les autorise mais exige une Rotation des Refresh Tokens. Chaque fois qu’un refresh token est utilisé, un nouveau est délivré, et l’ancien est invalidé. Si un attaquant utilise un refresh token volé, le serveur d’autorisation détecte la “rejouabilité” et tue toute la session.

7. Stratégie SEO : Implémenter OAuth 2.1 dès aujourd’hui

Pour les développeurs et architectes de sécurité souhaitant optimiser leur posture de sécurité (et leur référencement pour “Implémentation OAuth Sécurisée”), voici la checklist pour 2026 :

Mettre à jour votre bibliothèque : Assurez-vous que votre SDK (par ex., AppAuth, MSAL, OIDC-client-ts) est configuré par défaut pour PKCE.

Forcer S256 : Ne jamais utiliser la méthode “plain” de PKCE. Toujours utiliser S256 (SHA-256).

Auditer votre AS : Configurer votre serveur d’autorisation (Auth0, Okta, Keycloak, etc.) pour exiger PKCE pour tous les clients. Désactiver tout mode “Legacy” ou “Compatibilité”.

Supprimer les secrets du frontend : Si vous avez un client_secret dans votre code SPA ou mobile, supprimez-le. Il ne sert qu’à donner une fausse impression de sécurité.

Correspondance exacte : Auditer vos URI de redirection. Supprimer ceux utilisant des jokers (par ex., https://*.myapp.com).

Conclusion : La nouvelle référence

La finalisation d’OAuth 2.1 marque la fin d’une époque où une sécurité “suffisante” était acceptable. Les attaques par rétrogradation PKCE représentent une menace concrète pour toute application encore fidèle à OAuth 2.0 de 2012.

En rendant PKCE obligatoire, en supprimant le flux Implicite, et en appliquant une correspondance stricte des URI de redirection, OAuth 2.1 offre une défense robuste contre l’interception et l’injection. Il est temps de cesser de considérer la sécurité comme une “extension optionnelle” et de la traiter comme la base de votre application.