"nbf" claim timestamp check failed

jose (JavaScript) — JWTClaimValidationFailed, code ERR_JWT_CLAIM_VALIDATION_FAILED

Ce que cela signifie

Le jeton porte un claim `nbf` (« not before ») qui se situe encore dans le futur selon l’horloge du vérificateur : jose le refuse donc comme n’étant pas encore valide. La signature et les autres claims peuvent être parfaitement corrects ; l’erreur concerne uniquement le temps. Elle signifie presque toujours que l’écart entre les horloges de l’émetteur et du vérificateur dépasse la tolérance que vous accordez (zéro par défaut).

Pourquoi cela se produit

• L’horloge du vérificateur est en retard sur celle de l’émetteur

  fréquente

  De nombreux émetteurs fixent `nbf` à la date d’émission. Si l’horloge de l’hôte qui vérifie retarde ne serait-ce que de quelques secondes, chaque jeton fraîchement émis vient « du futur » pendant tout ce temps. Les conteneurs et les VM héritent de l’horloge de l’hôte : un seul hôte dont l’horloge dérive casse d’un coup tous les services qu’il héberge.

• Jeton utilisé dès son émission, sans tolérance

  fréquente

  Les tests et les appels de service à service créent souvent un jeton et l’envoient en quelques millisecondes. Avec `clockTolerance` à sa valeur par défaut de 0 seconde, le décalage normal entre deux machines suffit à provoquer des échecs intermittents.

• L’émetteur a délibérément fixé nbf dans le futur

  occasionnelle

  Certains systèmes émettent à l’avance des jetons qui deviennent valides plus tard (tâches planifiées, liens différés). Si un tel jeton est utilisé trop tôt, son rejet est correct : l’appelant doit attendre `nbf`.

• nbf écrit en millisecondes

  rare

  Les dates JWT sont exprimées en secondes depuis l’epoch (RFC 7519, NumericDate). Un émetteur qui écrit `Date.now()` produit un `nbf` situé environ 50 000 ans dans le futur, et le jeton n’est jamais valide.

Comment corriger l’erreur

1. 1.

   Autoriser un décalage d’horloge faible et explicite

   `clockTolerance` accepte un nombre de secondes ou une chaîne de durée. 30 à 60 secondes absorbent la dérive réelle ; ce n’est pas un moyen d’accepter des jetons plusieurs minutes en avance.

   import { jwtVerify } from "jose";
   
   const { payload } = await jwtVerify(token, jwks, {
     algorithms: ["ES256"],
     clockTolerance: "30s", // applies to nbf, exp and iat
   });

2. 2.

   Afficher la chronologie avant de modifier la configuration

   Comparez `nbf` avec l’heure actuelle du vérificateur. Un écart de quelques secondes indique un décalage d’horloge ; de plusieurs heures, un bug de fuseau horaire ou d’unité chez l’émetteur ; un `nbf` à 13 chiffres, des millisecondes.

   import { decodeJwt } from "jose";
   
   const { iat, nbf, exp } = decodeJwt(token);
   const now = Math.floor(Date.now() / 1000);
   console.log({ iat, nbf, exp, now, nbfInSeconds: nbf - now });

3. 3.

   Corriger l’horloge qui dérive

   Faites tourner NTP (chrony ou systemd-timesyncd) sur chaque hôte qui émet ou vérifie des jetons. La tolérance masque un faible décalage ; elle ne devrait pas avoir à masquer un décalage important.

   timedatectl status          # "System clock synchronized: yes"
   chronyc tracking            # offset from the NTP reference
   date -u +%s                 # compare with the token's nbf

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