jwt/

Non. Il se contente de décoder le Header et le Payload et ne vérifie jamais la signature : un décodage réussi ne prouve donc pas que le token est authentique ou non modifié. Vérifier une signature demande la clé secrète ou la clé publique et relève de votre backend, avec une bibliothèque JWT. De plus, le Payload est seulement encodé en base64url, pas chiffré : toute personne qui détient le token peut le lire, ne mettez donc ni mot de passe ni autre donnée sensible dedans.

Un JWT se compose de trois parties, header.payload.signature, reliées par des points, et tout autre nombre déclenche le message de nombre de parties incorrect. Les causes habituelles sont une copie incomplète, du texte en trop copié avec le token, ou quelque chose qui n'est pas du tout un JWT, comme un identifiant de session ou un token aléatoire opaque. Un token qui a exactement 5 parties est un JWE, dont le contenu est chiffré : il ne peut donc pas être décodé ici.

Cela signifie que l'une des parties contient un caractère qui n'a rien à faire dans un JWT, ou qu'elle a été tronquée. Le message nomme la partie et, pour un caractère illégal, indique lequel. Un JWT utilise base64url, qui ne comprend que des lettres, des chiffres, - et _, et un = final est facultatif. La cause la plus courante est un guillemet au début du token ; un + ou un / signifie que du Base64 ordinaire a été utilisé et qu'il faut les remplacer par - et _. Une copie tronquée donne généralement « longueur invalide » ou « n'est pas du JSON valide ».

Oui. Un Bearer en début de texte est retiré automatiquement (sans tenir compte de la casse), et les espaces, sauts de ligne et tabulations à l'intérieur du token sont ignorés : un token copié depuis un en-tête de requête ou un journal peut donc être collé tel quel. Une entrée de plus de 1 MB est rejetée d'emblée ; un vrai JWT fait en général de quelques centaines d'octets à quelques KB.

Ils proviennent de trois champs de temps du Payload. exp est l'heure d'expiration, et « Expiré » apparaît une fois qu'elle est passée ; nbf est l'heure de début de validité, et « Pas encore valide » apparaît avant elle ; iat est l'heure d'émission, et « Dans le futur » signifie qu'elle est postérieure à maintenant, ce qui peut indiquer un décalage d'horloge entre l'émetteur et votre ordinateur. La ligne « Statut » en haut vérifie d'abord nbf, puis exp, et n'affiche « Valide » que si les deux sont corrects ; cela ne concerne que la période de validité et ne dit rien de la signature.

La page utilise le fuseau horaire et l'horloge de votre ordinateur, et le fuseau est affiché après chaque date, par exemple UTC+08:00. exp, iat et nbf sont des horodatages Unix en secondes et ne dépendent pas d'un fuseau horaire ; un autre fuseau ne change que l'affichage du même instant. Le temps restant est actualisé chaque seconde et calculé à partir de l'heure actuelle de votre ordinateur : une horloge fausse donne donc des résultats faux. Une valeur très grande, comme un horodatage en millisecondes à 13 chiffres, reçoit une remarque indiquant que JWT utilise des secondes, et les autres champs de temps, comme auth_time, ne sont pas convertis automatiquement.

Oui, tous. Le décodage transforme seulement les deux premières parties en JSON et n'a rien à voir avec l'algorithme de signature. L'alg du Header est affiché à côté du titre, et quand alg vaut none, il est marqué « sans signature ». La partie Signature est affichée telle quelle en base64url et n'est pas décodée.

Non. Le décodage se fait dans votre navigateur et la page n'envoie le token nulle part. Cela dit, un token équivaut souvent à un identifiant de connexion : ne partagez pas à la légère un token actif encore valide, et ne le collez pas sur des sites que vous ne connaissez pas.