Durée de vie réelle d'un JWT : calcul epoch sur iat et exp

Lire une claim dans un JWT est une simple consultation. Juger un token demande de faire des calculs sur ses claims, et le chiffre le plus important d'une revue d'authentification n'est presque jamais écrit noir sur blanc : combien de temps un identifiant volé reste utilisable.

Un JWT comporte trois segments séparés par des points et le payload est encodé en base64url, pas chiffré, il se décode donc sans aucune clé. Deux claims enregistrées comptent ici. iat est la date d'émission et exp la date d'expiration, toutes deux en secondes epoch Unix comptées depuis le 1er janvier 1970 UTC. Aucune des deux n'est lisible telle quelle, et le token n'indique volontairement pas sa durée de vie.

Ce payload porte un iat de 1788858900 et un exp de 1796634900. La différence est de 7776000 secondes, et en divisant par 86400 on obtient exactement 90 jours, du 8 septembre au 7 décembre 2026.

La portée rend ce chiffre sérieux. C'est un token refresh, dont le seul rôle est de produire de nouveaux tokens d'accès. Un token d'accès de courte durée limite les dégâts à quelques minutes. Un refresh token avec une durée de vie de quatre-vingt-dix jours donne à un attaquant une clé renouvelable vers le compte pendant un quart d'année. Le payload n'a pas non plus de claim d'appareil ou d'installation, rien ne le relie donc au terminal auquel il a été délivré, et il peut être rejoué depuis n'importe où. Le jti est le seul signe encourageant, mais un identifiant de token n'aide que si le serveur tient une liste de révocation et la vérifie à chaque échange.

• Soumettre une valeur epoch. 1796634900 est l'instant d'expiration, pas la durée de vie. La réponse est la différence entre les deux claims.
• Diviser par la mauvaise constante. Un jour compte 86400 secondes. Diviser par 3600 donne des heures et par 60 des minutes.
• Répondre en mois. Quatre-vingt-dix jours représentent environ trois mois, mais la question demande des jours.
• Lire la claim exp en millisecondes. Les claims epoch d'un JWT sont en secondes. Les traiter comme des millisecondes fait paraître la durée de vie négligeable.
• Supposer qu'il faut d'abord vérifier la signature. Le payload reste lisible dans tous les cas, ce qui est la leçon de fond sur les JWT.

La fenêtre d'exposition est un choix de conception, et quatre-vingt-dix jours, c'est choisir d'en avoir une.

• Gardez des durées de vie courtes pour les refresh tokens, plutôt des jours que des mois, et réauthentifiez au lieu de prolonger indéfiniment.
• Faites pivoter les refresh tokens à chaque utilisation et détectez la réutilisation d'un token déjà pivoté, le signal le plus fiable qu'il a été volé.
• Liez le token à l'appareil ou à l'installation et rejetez-le s'il est présenté depuis un autre, pour que le vol seul ne suffise pas.
• Stockez les refresh tokens dans un stockage sécurisé fourni par la plateforme, le Keychain ou le Keystore, pas dans des shared preferences ou un plist qui finirait dans une sauvegarde.
• Maintenez une liste de révocation côté serveur indexée sur jti et vérifiez-la à chaque échange, pour que la déconnexion et la réponse à incident terminent réellement une session.
• Gardez des tokens d'accès de quelques minutes seulement, pour que le refresh token soit la seule chose qui vaille la peine d'être protégée, puis protégez-le correctement.