Timestamps Unix dans les tokens JWT
Mis à jour : mai 2026
Les tokens JWT utilisent des timestamps Unix pour leurs claims temporels. Les plus importants sont exp, iat et nbf. Ils sont exprimés en secondes, pas en millisecondes.
Gratuit · sans upload · calcul local
Les claims temporels
exp: expiration, le token ne doit plus être accepté après cet instant.iat: issued at, moment d'émission du token.nbf: not before, le token ne doit pas être accepté avant cet instant.
Secondes, pas millisecondes
Dans un JWT, ces valeurs suivent le type NumericDate de la RFC 7519 : nombre de secondes depuis l'epoch Unix. Envoyer Date.now() directement dans exp crée un token valable pendant des dizaines de milliers d'années.
Exemple
{
"iat": 1735689600,
"nbf": 1735689600,
"exp": 1735693200
}Ici, le token est émis à minuit UTC et expire une heure plus tard.
JavaScript
const now = Math.floor(Date.now() / 1000);
const payload = {
iat: now,
nbf: now,
exp: now + 3600
};
Clock skew
Les serveurs tolèrent souvent quelques secondes de décalage d'horloge entre machines. Cette tolérance s'appelle clock skew. Elle ne doit pas masquer une mauvaise unité : un écart de 1000x indique presque toujours une confusion secondes / millisecondes.
Questions fréquentes
exp est-il inclus ou exclu ?
Le token ne doit plus être accepté à partir de l'instant exp. En pratique, vérifiez la logique exacte de votre librairie.
Pourquoi mon JWT expire immédiatement ?
Vérifiez le fuseau et surtout l'unité. exp doit être un timestamp en secondes.
Puis-je lire exp sans vérifier la signature ?
Vous pouvez le décoder pour déboguer, mais toute décision de sécurité doit vérifier la signature.