Authentification : JWT, OAuth, sessions, les failles qu'on voit le plus

> En bref : Les erreurs d'implémentation les plus fréquentes sur JWT, OAuth 2.0 et les sessions classiques, avec des exemples concrets et les corrections.

L'authentification, maillon faible numéro un

L'authentification est le mécanisme le plus critique de toute application. Une faille ici donne un accès direct aux comptes utilisateurs. Malgré la maturité des bibliothèques disponibles, nous trouvons des erreurs d'implémentation dans la majorité des applications auditées chez CleanIssue.

JWT : les erreurs classiques

Algorithm confusion (alg=none)

Le standard JWT permet de spécifier l'algorithme de signature dans le header. Certaines bibliothèques acceptent "alg": "none" et considèrent le token comme valide sans vérifier aucune signature. L'attaquant forge un token avec les claims de son choix.

Correction : spécifiez explicitement l'algorithme accepté côté serveur. Ne faites jamais confiance au champ alg du token.

Confusion RS256/HS256

Si le serveur utilise RS256 (asymétrique) mais accepte aussi HS256 (symétrique), l'attaquant signe le token avec la clé publique (qui est publique) en utilisant HS256. Le serveur vérifie avec la même clé publique et accepte le token.

Absence d'expiration

Un JWT sans claim exp est valide indéfiniment. Si un token fuite (logs, URL, cache), il reste exploitable pour toujours. Pire : même avec un exp, si le serveur ne le vérifie pas, le token n'expire jamais en pratique.

Correction : durée de vie courte (15 minutes) pour les access tokens, refresh tokens avec rotation et stockage sécurisé.

Secret faible

Un secret HMAC comme secret, password ou le nom de l'entreprise. Des outils comme jwt-cracker testent des dictionnaires de secrets courants en quelques secondes.

OAuth 2.0 : les pièges d'implémentation

PKCE désactivé

OAuth 2.0 avec le flow Authorization Code sans PKCE est vulnérable à l'interception du code d'autorisation. PKCE (Proof Key for Code Exchange) est obligatoire depuis OAuth 2.1 mais beaucoup d'implémentations ne l'activent pas.

Redirect URI lax

Si la validation du redirect_uri est trop permissive (accepte des sous-chemins ou des sous-domaines), un attaquant redirige le code d'autorisation vers une URL qu'il contrôle. https://app.com.evil.com/callback peut passer un filtre qui vérifie juste app.com.

State parameter manquant

Sans le paramètre state, l'application est vulnérable aux attaques CSRF sur le flow OAuth. L'attaquant peut lier son propre compte tiers au compte de la victime.

Scope trop large

L'application demande scope=admin quand elle n'a besoin que de scope=read:profile. Si le token fuite, l'attaquant a des privilèges excessifs.

Sessions classiques : les oublis

Cookies non sécurisés

Un cookie de session sans les flags Secure, HttpOnly et SameSite est vulnérable à l'interception (sans Secure), au vol via XSS (sans HttpOnly), et aux attaques CSRF (sans SameSite).

Invalidation incomplète

L'utilisateur clique sur Déconnexion mais la session côté serveur n'est pas détruite. Le cookie reste valide et utilisable. Encore pire si les sessions n'ont pas de durée de vie maximale.

Fixation de session

L'application ne renouvelle pas l'identifiant de session après l'authentification. L'attaquant fixe un identifiant de session connu, la victime s'authentifie, l'attaquant utilise le même identifiant maintenant authentifié.

Entropie insuffisante

Des identifiants de session prédictibles (basés sur le timestamp, l'ID utilisateur, ou un compteur) permettent à un attaquant de deviner ou brute-forcer des sessions actives.

Recommandations transversales

Parlez-nous de votre revue externe CleanIssue pour auditer votre système d'authentification.

À retenir