jwt expired

Ce que cela signifie

TokenExpiredError de jsonwebtoken : le claim exp du jeton (un horodatage Unix en secondes) est antérieur à l’heure actuelle de l’horloge du vérificateur. La signature elle-même peut être parfaitement valide : le jeton a simplement dépassé la durée de vie que l’émetteur lui a donnée. L’objet d’erreur porte expiredAt avec l’instant exact.

Pourquoi cela se produit

• Le jeton a réellement expiré

  fréquente

  Les jetons d’accès à courte durée de vie (de 5 à 60 minutes) sont la norme ; un client qui met un jeton en cache et le réutilise plus tard, ou une tâche de fond qui garde un jeton pendant une longue exécution, tombera sur cette erreur exactement à l’heure prévue. La correction est un flux d’actualisation, pas une durée de vie plus longue.

• Décalage d’horloge entre l’émetteur et le vérificateur

  fréquente

  Si l’horloge du serveur vérificateur avance par rapport à celle de l’émetteur, les jetons « expirent » trop tôt, parfois dès leur émission. Les conteneurs et les VM sans NTP dérivent étonnamment vite ; un décalage de deux minutes suffit à casser par intermittence des jetons valables moins d’une heure.

• exp écrit dans la mauvaise unité

  occasionnelle

  La spécification (RFC 7519) définit exp en secondes. Du code qui divise par 1000 une fois de trop produit des horodatages en 1970, si bien que chaque jeton est expiré dès sa création. L’étourderie inverse – écrire Date.now() (en millisecondes) dans exp – ne déclenche pas du tout cette erreur : elle produit des horodatages situés plus de 56 000 ans dans le futur, et le jeton n’expire jamais.

Comment corriger l’erreur

1. 1.

   Tolérer explicitement un léger décalage

   clockTolerance s’exprime en secondes et s’applique à exp et à nbf. Gardez une valeur faible (de 30 à 60 s) : cette option sert à absorber la dérive d’horloge, pas à prolonger la durée de vie des jetons.

   jwt.verify(token, publicKey, {
     algorithms: ["ES256"],
     clockTolerance: 30, // seconds of tolerated skew
   });

2. 2.

   Examiner exp avant d’accuser l’horloge

   Décodez les claims et affichez exp à côté de l’heure actuelle. Si exp ressemble à 1.7e12, vous avez un bug de millisecondes ; s’il est dépassé de quelques minutes, il vous faut une logique d’actualisation.

   const { exp } = jwt.decode(token);
   console.log("exp:", new Date(exp * 1000).toISOString());
   console.log("now:", new Date().toISOString());

3. 3.

   Synchroniser les horloges et ajouter un mécanisme d’actualisation

   Faites tourner NTP (chrony/systemd-timesyncd) sur les hôtes qui vérifient les jetons, et implémentez côté client l’actualisation du jeton en cas de réponse 401. Ne livrez jamais ignoreExpiration: true en production : cette option transforme chaque jeton divulgué en informations d’identification permanentes.

← Parcourir toute la base de données des erreurs de signature