Pourquoi votre JWT expire immédiatement : l'exp est en secondes, pas en millisecondes

Émis à 10:00, expiré à 10:00 — un jeton rejeté lors de sa première utilisation et une horloge de serveur qui n'était pas le problème

Un jeton rejeté lors de sa première requête suscite des soupçons de biais du serveur, mais inspectez les réclamations brutes avant de changer d'horloge. Si un composant a généré `exp` à partir d’une horloge milliseconde tandis qu’un autre compare les secondes NumericDate, les valeurs diffèrent de trois ordres de grandeur. Aucun ajustement de synchronisation ordinaire n’explique cet écart.

Utilisez un jeton jetable ou expurgé, car un jeton de porteur est un identifiant. Le décodeur JWT de ToolAcre lit les données utiles mais ne vérifie délibérément pas les signatures. Copiez la demande d'heure numérique dans le convertisseur d'horodatage uniquement après avoir conservé le dispositif de test d'origine et sa durée de vie prévue.

Ce que dit la RFC 7519 — NumericDate en secondes depuis 1970-01-01T00:00:00Z, et pourquoi il s'agit d'un nombre plutôt que d'une chaîne

L'article JWT publié adjacent indique déjà le contrat crucial : `exp` NumericDate compte les secondes à partir de l'époque Unix. Répéter son explication standard n’ajouterait aucune valeur ici. La question pratique est de savoir si chaque producteur, sérialiseur, vérificateur et dispositif de test respecte la même échelle.

Recherchez un code limite explicite : une horloge en millisecondes divisée en secondes lors de l'émission et une comparaison des secondes lors de la validation. La déclaration doit rester un nombre plutôt qu'une date formatée utilisée pour l'arithmétique. L'UTC lisible par l'homme est une projection de diagnostic, et non la représentation faisant autorité du jeton.

Épinglez ce contrat dans les tests de l'émetteur et du vérificateur avec une valeur non nulle. Un test utilisant l’époque zéro ne peut pas révéler si l’un ou l’autre côté a divisé ou multiplié par mille.

L'article JWT existant établit les secondes NumericDate ; cet article applique ce fait au débogage d'expiration

Si un vérificateur interprète une réclamation de secondes valide en millisecondes, la date se rapproche de 1970 et semble expirée. Si un émetteur écrit une valeur actuelle en millisecondes dans un champ interprété ultérieurement en secondes, l'expiration dépasse largement la durée de vie prévue ou au-delà de la plage prise en charge par une bibliothèque. Le symptôme qui apparaît identifie le côté qui possède l'erreur d'échelle.

Évitez un « correctif » qui accepte les deux formulaires en fonction du nombre de chiffres. Cela transforme les jetons mal formés en un protocole alternatif permanent et peut masquer les régressions des émetteurs. Rejetez les valeurs qui violent le contrat NumericDate de l'application, corrigez la génération et ajoutez des appareils qui distinguent les secondes des millisecondes.

Des erreurs d'une milliseconde peuvent entraîner un rejet immédiat ou une expiration invraisemblable à distance, selon le côté qui a tort.

Décodez la charge utile pour exposer `exp`, `iat` et `nbf` en tant que valeurs brutes avant qu'un framework ne les convertisse. Comparez `exp − iat` à la durée de vie prévue du jeton en secondes. Cochez `nbf` séparément ; un jeton peut être non expiré mais inutilisable. Ne déduisez pas l’authenticité de délais raisonnables.

Le décodeur de ToolAcre signale que la vérification de la signature est fausse, sa sortie appartient donc au débogage, jamais à l'autorisation. Une charge utile modifiée peut contenir n’importe quelle expiration choisie par un attaquant. Le vérificateur d’applications de confiance doit toujours appliquer la politique d’algorithme, de clé, d’émetteur, d’audience et de temps sur le jeton compact d’origine.

Exemple concret : une expérience de 1700003600 — en la convertissant en UTC et en heure locale, en la vérifiant par rapport à iat et en confirmant que la durée de vie correspond à ce que vous vouliez

Pour `iat = 1,700,000,000` et `exp = 1,700,003,600`, la soustraction donne 3,600 secondes, soit une heure. Le convertisseur lit explicitement l'expiration en secondes et renvoie `2023-11-14T23:13:20.000Z` ; l'heure d'émission est le `2023-11-14T22:13:20.000Z`.

Ces numéros sont uniques à l'exemple de diagnostic de cet article. Si la sélection des millisecondes produit une lecture de janvier 1970, cela est probablement une preuve d'une mauvaise échelle. Confirmez que l’heure actuelle du vérificateur est également exprimée en secondes avant de conclure que la politique d’une heure est correctement mise en œuvre.

La différence d'une heure est calculée avant le formatage, elle reste donc une heure dans chaque zone. Les affichages locaux peuvent différer, mais pas `exp − iat`.

Exemple concret : comparez l'exp 1,700,003,600 avec un iat à proximité en utilisant des secondes explicites

Un vérificateur peut autoriser une petite tolérance définie par l'application autour des demandes de temps pour s'adapter à de modestes différences d'horloge. Ce référentiel ne définit pas de nombre de secondes recommandé, aucune marge de manœuvre universelle n'est donc prescrite ici. La politique de sécurité et la configuration de la bibliothèque font autorité.

La tolérance doit rester minime par rapport à un facteur mille. L'étendre jusqu'à ce qu'une réclamation mal formée soit adoptée affaiblit l'application de l'expiration et laisse le bug de l'émetteur en vie. Normalisez d’abord les unités d’horloge et la synchronisation ; décidez ensuite si une allocation limitée sert le modèle de menace de l’application.

Si une tolérance est configurée, testez les valeurs juste à l'intérieur et à l'extérieur de cette limite en quelques secondes. Cela prouve la politique indépendamment de tout rendu de date ou de paramètres régionaux.

La tolérance ne peut pas réparer une inadéquation de facteur de 1,000

La conversion d'horodatage ne peut pas vérifier la signature d'un jeton, l'algorithme autorisé, la clé, l'émetteur ou l'audience. Même une future réclamation `exp` parfaitement formatée peut se trouver à l’intérieur d’un jeton contrefait. Le décodeur JWT est intentionnellement transparent sur cette limite et doit être associé à un vérificateur de confiance.

Il ne peut pas non plus établir si un jeton de production capturé a été révoqué ou si une politique de session annule son expiration nominale. Déboguer les valeurs avec des appareils non sensibles. Si un incident réel nécessite l'examen des informations d'identification, utilisez l'environnement autorisé et la procédure de traitement plutôt que le flux de travail général du presse-papiers.

Le décodage ne devrait avoir lieu qu'avec des appareils synthétiques ou rédigés en toute sécurité lors du débogage de routine. La copie d'un identifiant de porteur en direct crée un problème de sécurité sans rapport avec l'arithmétique de l'horodatage.

À retenir : exp est composé de dix chiffres et non de treize – et comment le décodeur JWT et le convertisseur d'horodatage Unix se trouvent dans le même onglet afin que vous puissiez vérifier une réclamation en quelques secondes.

Traitez les revendications de temps JWT comme des secondes à chaque limite et testez leurs différences comme des durées. Le convertisseur d'horodatage transforme une revendication individuelle en UTC et en contexte local ; le décodeur JWT expose le nombre brut. Ensemble, ils expliquent le timing sans revendiquer la confiance.

La correction durable appartient au code d'émission et de vérification, et non à un runbook de support qui change d'unité jusqu'à ce qu'un jeton fonctionne. Préservez les secondes explicites, rejetez l’échelle mal formée et conservez la vérification de la signature en tant que décision obligatoire distincte.

Cette séparation améliore également l'observabilité : les journaux de génération peuvent signaler une politique de durée sans exposer les jetons, tandis que les mesures de vérification peuvent distinguer les résultats de signature expirés, prématurés et invalides.