Outils de développement · Décodeur JWT
JWT exp, iat et nbf : NumericDate est en secondes, pas en millisecondes
· Comment ça marche
jwt horodatages Validation débogage
JavaScript vous donne des millisecondes et JWT veut des secondes, donc les horodatages sont erronés d'un facteur mille. Cet article explique NumericDate et comment lire correctement les trois revendications de temps.
Des jetons qui n'expirent jamais ou expirent avant leur arrivée — les deux symptômes d'une erreur d'unités
Une erreur d'un facteur mille produit des symptômes dramatiques. Fournir des millisecondes JavaScript là où un producteur de jetons s'attend à des secondes d'époque peut repousser l'expiration de plusieurs milliers d'années. Diviser à nouveau une valeur en secondes peut la placer près de 1970, faisant apparaître un jeton nouvellement émis expiré avant sa première demande légitime.
Un décodeur permet d'exposer l'échelle en affichant la déclaration numérique à côté d'une lecture ISO. Cet affichage est uniquement diagnostique. Un attaquant peut écrire n'importe quel numéro `exp`, `iat` ou `nbf` dans une charge utile non signée ou falsifiée, de sorte que l'heure convertie n'a d'autorité qu'après la signature et la validation de la politique ailleurs.
NumericDate dans RFC 7519 — secondes depuis l'époque Unix, sous forme de nombre JSON, avec des fractions autorisées mais rarement utilisées
JWT les revendications de temps utilisent une représentation NumericDate : un nombre JSON comptant les secondes à partir de l'époque Unix. Les nombres fractionnaires peuvent représenter des positions inférieures à la seconde car l'implémentation multiplie la valeur par 1,000 avant de construire une date. Il n’arrondit pas d’abord un nombre fini valide à un nombre entier.
ToolAcre reconnaît `exp`, `nbf`, `iat`, `auth_time` et `updated_at` comme champs d'affichage en forme de temps. Seules les trois premières figurent parmi les descriptions de revendications enregistrées. Les résultats de date non numériques, infinis ou invalides sont omis plutôt que d'être affichés sous forme d'heures significatives, empêchant ainsi une chaîne telle que « bientôt » de se faire passer pour un horodatage.
Date.now() correspond à des millisecondes — l'habitude JavaScript qui produit des expirations dans un futur lointain
`Date.now()` renvoie des millisecondes, tandis qu'une valeur NumericDate est exprimée en secondes. Un producteur déduisant une réclamation de l'horloge du navigateur a donc besoin d'une conversion d'échelle explicite, généralement en divisant par 1,000 avant d'appliquer sa propre politique d'arrondi. Le chemin de lecture ToolAcre effectue la multiplication inverse uniquement à des fins d'affichage.
Gardez la conversion d'unité visible dans la révision du code. Une valeur à treize chiffres dans `exp` est un signe d’avertissement utile, mais le comptage des chiffres ne constitue pas une vérification et ne peut pas remplacer le contrat du producteur. Le décodeur tentera de restituer toute revendication numérique finie que JavaScript Date peut représenter ; il ne réinterprète pas silencieusement les millisecondes en secondes.
exp, nbf et iat – expirent, pas avant et émis à, et comment un vérificateur les applique chacun
`exp` nomme le délai après lequel un vérificateur ne devrait plus accepter de jeton en vertu de sa politique. `nbf` nomme une limite avant laquelle il ne doit pas être accepté. `iat` enregistre une heure d'émission. ToolAcre étiquette ces significations et compare uniquement `exp` et `nbf` avec l'horloge de référence fournie.
L'état renvoyé est `expired` lorsque l'expiration décodée est antérieure à maintenant, `future` lorsque le non-avant est postérieur à maintenant et `past` pour les autres revendications de temps affichées. Ces étiquettes sont des observations sur l'arithmétique de la charge utile. Ils ne constituent pas une décision d’authentification et n’évaluent pas l’émetteur, l’audience, la clé ou la signature.
Les différences d'horloge et les marges de manœuvre appartiennent au vérificateur ; ce décodeur ne définit ni
Le plan demandait quel décalage d'horloge est raisonnable, mais ni la configuration du décodeur JWT ni l'implémentation ne définissent de marge de manœuvre. Ce numéro appartient au vérificateur et à ses exigences de déploiement. Inventer une valeur par défaut ici transformerait un article d'inspection en politique de sécurité non documentée, c'est pourquoi cette section n'en fournit intentionnellement aucune.
Si un service rejette un jeton à proximité d'une limite, comparez l'horloge du service, l'horloge de l'émetteur et la stratégie de vérification configurée à l'aide de journaux fiables. ToolAcre résout les réclamations par rapport à la date actuelle du navigateur sans fenêtre de tolérance. Son résultat peut donc différer de celui d'un serveur qui applique délibérément une marge de manœuvre, même lorsque les deux analysent le même numéro.
Exemple concret : conversion d'un exemple de valeur d'expérience en une heure lisible par l'homme et vérification par rapport à iat
Supposons qu'une charge utile synthétique contienne `iat: 1717243200` et `exp: 1717246800`. La multiplication par 1,000 donne les instants ISO `2024-06-01T12:00:00.000Z` et `2024-06-01T13:00:00.000Z`. La soustraction des valeurs brutes des secondes donne un intervalle d'une heure sans mélanger les millisecondes du navigateur dans le calcul.
Cette arithmétique décrit ce que dit la charge utile. Cela ne montre pas que l'émetteur a choisi ces valeurs ou qu'une heure convient à n'importe quelle application. ToolAcre imprime joliment les nombres, génère des lignes UTC et peut appeler l'expiration par rapport à aujourd'hui ; un vérificateur doit authentifier et appliquer de manière indépendante ses propres règles d'acceptation.
Ce que cela ne couvre pas : si un serveur spécifique acceptera le jeton, ce qui dépend de son horloge et de sa marge de manœuvre ; un décodeur affiche les valeurs, pas le verdict
Un décodeur ne peut pas prédire si un serveur spécifique acceptera le jeton. Le serveur peut utiliser une horloge différente, une tolérance configurée, un schéma de réclamation plus strict ou des contrôles supplémentaires de l'émetteur et de l'audience. L'échec de la signature à lui seul peut rejeter un jeton dont les NumericDates affichées semblent parfaitement ordinaires.
À l'inverse, une expiration prospective ne rend pas valide un jeton non vérifié. Considérez le calendrier comme un moyen de repérer les erreurs probables des unités et de rassembler des preuves pour le débogage. Le verdict réel appartient aux journaux du serveur ou à un test de vérification contrôlé avec la clé et la politique attendues, jamais dans le panneau de décodage.
À retenir : lisez les revendications, faites l'arithmétique – le décodeur ToolAcre JWT affiche exp, iat et nbf afin que vous puissiez vérifier les unités vous-même
Lisez les revendications et effectuez délibérément des calculs d'échelle : les secondes NumericDate deviennent des millisecondes JavaScript uniquement à la limite de la date. ToolAcre rend cette multiplication explicite dans la source et affiche la valeur ISO résultante, tout en ignorant les types d'heure mal formés au lieu de deviner ce que leurs auteurs voulaient.
Gardez la distinction de sécurité également explicite. Un affichage `exp` ne constitue pas une application de l'expiration, un affichage `nbf` n'est pas un contrôle d'admission et `iat` n'est pas une preuve de délivrance. Après avoir inspecté un jeton jetable, utilisez le vérificateur de confiance pour l’authentifier et appliquez l’horloge réelle et la politique de réclamation du service.