Vérifier l’expiration d’un JWT
Le claim exp est un horodatage Unix, qui ne dit rien au premier coup d’œil. Collez le jeton : cette page en fait une date, dans votre fuseau, et une phrase claire.
Signez votre propre jeton pour tester un point d’accès. Tout est calculé dans cette page.
La clé et le jeton obtenu restent dans votre navigateur : rien n’est envoyé nulle part, et rien de tout cela ne figure dans un lien partagé.
Vérifiez ce jeton dans votre propre code. L’extrait suit l’algorithme indiqué dans l’en-tête.
Savoir quand un JSON Web Token expire
Une requête refusée reste rarement longtemps mystérieuse : la première chose à regarder est si le jeton était encore vivant à son arrivée. Le problème, c’est que la réponse est stockée sous la forme 1790208000, et personne ne lit cela d’un coup d’œil. Collez le jeton : la ligne au-dessus de l’en-tête décodé le dit en toutes lettres — expiré il y a deux jours, expire dans cinquante-huit minutes, pas encore valide — tandis que le tableau des claims donne la date complète dans votre fuseau.
Tout est décodé dans la page. Cela compte ici, car un jeton est un accès vivant : quiconque en détient un valide peut généralement agir comme son sujet jusqu’au moment précis dont cette page vous parle. Rien de ce que vous collez n’est envoyé, journalisé ni conservé.
Les trois claims qui portent le temps
| Claim | Sens | À quoi ressemble une mauvaise valeur |
|---|---|---|
exp | Le jeton cesse d’être accepté à ce moment | Un 401 qui revient toujours au même délai après chaque connexion |
nbf | Il ne peut pas servir avant ce moment | Un jeton tout neuf refusé pendant ses premières secondes |
iat | Quand il a été émis | Utilisé par les règles d’âge maximal : un jeton ancien mais non expiré échoue quand même |
Les trois comptent des secondes depuis l’époque Unix, pas des millisecondes — un JWT écrit à la main avec un Date.now() JavaScript atterrit en l’an 58 000 et n’est accepté par personne. Si vous devez convertir l’un de ces nombres isolément, le convertisseur d’horodatage fait le même calcul dans les deux sens.
Expiré, ou simplement décalé ?
Deux machines s’accordent rarement à la seconde près, donc tout vérificateur raisonnable laisse une marge — trente à soixante secondes en général. C’est cette tolérance qui explique qu’un jeton paraisse expiré ici de quelques secondes et soit tout de même accepté, et qu’un jeton émis par un serveur dont l’horloge avance soit refusé comme pas encore valide dans ses premiers instants. Si un jeton échoue bien au-delà de cette fenêtre, l’horloge n’est pas en cause.
L’autre moitié de la réponse, c’est la signature. Un jeton expiré peut porter une signature parfaitement valide, et un jeton falsifié peut annoncer un exp très lointain ; les deux questions sont indépendantes. Cette page répond aux deux : vérifiez la signature avec la clé placée sous le jeton, et un résultat expiré continue d’être signalé à côté de la signature valide.
Combien de temps un jeton devrait vivre
Peu, car un jeton ne se reprend pas. Une fois signé, celui qui le détient est cet utilisateur jusqu’à ce que exp passe ; un jeton d’accès qui vit un quart d’heure limite donc les dégâts d’une fuite comme un jeton de trente jours ne le fera jamais. L’arrangement habituel associe un jeton d’accès court et un jeton de rafraîchissement long, conservé côté serveur et révocable — c’est exactement l’arbitrage qu’examine la comparaison avec les cookies de session.
Si vous cherchez à tester ce comportement plutôt qu’à le diagnostiquer, le générateur de JWT signera un jeton qui expire dans cinq minutes, ou un jeton sans expiration du tout, pour voir comment votre propre code réagit.