Sessions JWT résistantes au replay

Les JWT bearer sont simples parce que la possession suffit. C’est aussi le problème. Si un attaquant récupère le jeton depuis des logs, un malware, un proxy, une extension de navigateur ou un ticket support copié, l’API ne sait généralement pas distinguer l’attaquant de l’utilisateur. La résistance au replay consiste à réduire cet écart sans prétendre qu’un JWT devient soudain une credential liée au matériel.

Commencer par les chemins de fuite

Avant d’ajouter des mécanismes, cartographie où voyagent les tokens. Les en-têtes Authorization traversent load balancers, logs applicatifs, agents APM, reporters d’erreurs, reverse proxies et parfois des intégrations contrôlées par des clients. Les tokens navigateur peuvent apparaître dans des outils de session replay ou des commandes curl copiées. Les tokens mobiles peuvent finir dans des crash reports. Tout design anti-replay échoue si l’organisation duplique encore les bearer tokens dans des endroits lisibles par un attaquant.

Les durées courtes aident, mais seulement après réduction des fuites. Un token de cinq minutes dans des logs verbeux reste un accès distant à l’API pendant cinq minutes s’il porte des droits larges. Scope et audience comptent autant que la durée.

jti et état de session serveur

Ajouter jti donne un identifiant à chaque jeton. Il devient utile quand le vérificateur peut comparer cet identifiant à un état de session, une liste de révocation ou une chaîne de rotation. Sans lookup, jti n’est qu’une étiquette. Avec lookup, tu retrouves des propriétés de session: révoquer un appareil, détecter la réutilisation après rotation de refresh, invalider après réinitialisation d’identifiants.

Détecter les motifs de replay

Ne bloque pas uniquement parce que l’IP change. Les réseaux mobiles et VPN d’entreprise rendent ce signal bruyant. Combine plutôt les indices: voyage impossible, changement de famille user agent, nouvel appareil, réutilisation d’un ancien refresh token et accès depuis une région jamais vue pour le compte. Journalise assez pour enquêter, mais jamais les tokens complets. Hache jti ou les identifiants de session si les logs quittent la frontière de confiance.

Options plus fortes

Les approches proof of possession lient le token à une clé que le client doit utiliser à chaque requête. DPoP et mTLS en sont des exemples, mais ajoutent un coût opérationnel. Elles conviennent aux APIs de forte valeur, clients machine, intégrations partenaires et surfaces administratives. Pour des sessions web ordinaires, rotation de refresh bien gérée, cookies HttpOnly, scopes étroits et révocation rapide offrent souvent un meilleur compromis.

Conception pratique

Traite la résistance au replay comme des couches. Réduis l’exposition des tokens, garde des access tokens courts, fais tourner les refresh tokens, stocke l’état de session côté serveur et alerte sur les signaux de réutilisation. Le JWT peut rester la credential de requête pendant que le modèle de session vit ailleurs. Cette séparation fait souvent la différence entre "volé une fois, valable partout" et "volé une fois, contenu vite".