Expiration JWT et dérive d’horloge

Les bugs d’expiration JWT ne viennent presque jamais d’une incompréhension de exp. La plupart des ingénieurs savent qu’il s’agit d’un timestamp Unix et qu’un jeton expiré doit échouer. Les ennuis commencent aux bords: files de retry, mobiles avec une mauvaise horloge, workers CDN dans plusieurs régions et services qui n’acceptent pas la même dérive. Cinq minutes de tolérance peuvent améliorer la fiabilité ou prolonger discrètement chaque jeton volé.

Les claims sont simples, le système ne l’est pas

exp indique quand le jeton cesse d’être valide. nbf indique quand il commence. iat indique quand il a été émis, mais beaucoup de vérificateurs le traitent comme informatif sans politique explicite. Dans un seul processus avec NTP correct, c’est simple. Dans une pile distribuée, le jeton peut être créé dans une région, vérifié dans une autre, rejoué par un client après timeout, puis transmis à une file de workers quelques secondes plus tard.

Les attaquants regardent la fenêtre de tolérance. Si les access tokens durent officiellement dix minutes et que le vérificateur accepte cinq minutes de dérive, la durée utile après vol se rapproche de quinze minutes. Si les endpoints de refresh utilisent une tolérance différente des APIs, un jeton volé peut échouer ici et se renouveler ailleurs.

Choisir une fenêtre de dérive

Utilise la plus petite dérive compatible avec le comportement mesuré de tes horloges, pas une valeur héritée. Trente à soixante secondes suffisent souvent pour des systèmes serveur avec synchronisation saine. Les clients mobiles ou desktop peuvent se tromper de plusieurs minutes, mais le serveur reste l’autorité. Si l’horloge client est mauvaise, améliore l’UX de refresh et de retry plutôt que d’accorder une longue grâce à tous les jetons.

Cas limites à tester

Teste des jetons expirés depuis une seconde, juste dans la fenêtre et juste hors fenêtre. Teste nbf dans le futur proche. Teste iat loin dans le futur, car certains systèmes acceptent par erreur des jetons de demain. Teste aussi les jobs en arrière-plan. Si une requête met du travail en file avec un jeton qui expire avant l’exécution, le worker doit utiliser une décision d’autorisation dérivée ou un identifiant de service, pas refaire confiance à un vieux jeton utilisateur.

Journaux et incidents

Journalise l’horloge du vérificateur, le timestamp du claim, la dérive appliquée et la raison de l’échec. Sans ces champs, les incidents d’expiration deviennent des devinettes. Ne journalise jamais les jetons bruts. Lors d’un soupçon de vol, réduire la dérive peut contenir l’impact, mais seulement si tu sais quels services l’appliquent réellement.

Une politique saine

Access tokens courts, faible dérive, refresh explicite et code de vérification commun valent mieux que des exceptions malignes. Documente l’interprétation exacte de exp, nbf et iat par émetteur. La politique doit être assez simple pour qu’un ingénieur d’astreinte prévoie le résultat à partir de trois timestamps et d’un nom de service.