OAuth 2.0 PKCE : quand la protection est désactivée sans le savoir

> En bref : Le flux PKCE protège contre l'interception de code d'autorisation. Mais quand il est mal implémenté, il donne un faux sentiment de sécurité.

PKCE : la protection que tout le monde croit avoir

PKCE (Proof Key for Code Exchange) est devenu le standard de sécurité pour les flux OAuth 2.0, notamment pour les applications SPA et mobiles. Il protège contre l'interception du code d'autorisation. Le problème : de nombreuses implémentations le désactivent sans le savoir.

Comment PKCE fonctionne

Le client génère un code_verifier aléatoire et envoie son hash (code_challenge) avec la requête d'autorisation. Lors de l'échange du code contre un token, le client envoie le code_verifier original. Le serveur vérifie que le hash correspond. Un attaquant qui intercepte le code d'autorisation ne peut pas l'échanger sans le code_verifier.

Le cas que nous avons trouvé : un portail de santé

Lors d'un audit sur une plateforme de santé utilisant OAuth pour l'authentification des praticiens, nous avons découvert que le flux PKCE était techniquement implémenté mais neutralisé. Le code_verifier était exposé via un endpoint non authentifié de l'application. Concrètement, un attaquant pouvait récupérer le code_verifier d'une session en cours, intercepter le code d'autorisation (via un réseau partagé ou une extension malveillante), et compléter le flux OAuth pour obtenir un token d'accès valide.

Le résultat : accès complet au dossier médical du praticien et à tous ses patients. La plateforme pensait être protégée par PKCE : elle ne l'était pas.

Les 4 erreurs d'implémentation PKCE les plus courantes

1. code_verifier stocké côté serveur accessible : le code_verifier est censé rester exclusivement côté client. Si votre backend le stocke et l'expose via une API, la protection est annulée.

2. code_challenge_method absent : sans spécifier S256 comme méthode de challenge, certains serveurs OAuth acceptent plain : le code_challenge EST le code_verifier, supprimant toute protection.

3. Serveur OAuth qui n'enforce pas PKCE : si le serveur accepte les échanges de code sans code_verifier, PKCE est optionnel et un attaquant peut simplement l'ignorer.

4. code_verifier prévisible : utiliser un UUID ou un timestamp au lieu d'un aléa cryptographique de 43+ caractères rend le code_verifier devinable.

Comment vérifier votre implémentation

L'impact pour les PME

Si votre application utilise OAuth (Login with Google, Azure AD, Auth0, Keycloak), vérifiez que PKCE est réellement actif. Une faille OAuth donne un accès complet à la session utilisateur : pas seulement à un endpoint. Notre revue externe teste systématiquement les flux d'authentification OAuth.

À retenir