jwt malformed

Ce que cela signifie

jwt.verify() de jsonwebtoken n’a même pas pu analyser le jeton : la chaîne ne se découpe pas en exactement trois segments séparés par des points. La signature n’a jamais été vérifiée : la chaîne que vous avez passée n’a pas la structure d’un JWT. (Une chaîne qui a bien trois segments, mais dont l’en-tête n’est pas du JSON en base64url, échoue une étape plus loin, avec « invalid token ».)

Pourquoi cela se produit

• L’en-tête Authorization a été mal découpé

  fréquente

  La valeur de l’en-tête Authorization est « Bearer eyJ... », et le code en a gardé la mauvaise moitié : auth.split(" ")[0] passe à jwt.verify() le schéma « Bearer » lui-même, qui ne contient aucun point. Passer la chaîne « Bearer eyJhbGci... » entière échoue autrement : elle se découpe toujours en trois segments, si bien que jsonwebtoken signale « invalid token » lorsque le premier ne se décode pas.

• La mauvaise variable est arrivée dans verify()

  fréquente

  Une chaîne qui n’est pas un jeton s’est retrouvée à la place du jeton : « undefined » ou « null » issus de l’interpolation d’une valeur absente (un client qui envoie « Bearer null » parce que rien n’avait été stocké, un req.headers.authorisation mal orthographié, un cookie manquant), « [object Object] » issu de la conversion en chaîne de la charge utile décodée au lieu de la transmission du jeton brut, ou un ID utilisateur. Une vraie valeur undefined, null ou une chaîne vide est interceptée une vérification plus tôt, avec « jwt must be provided ».

• Le jeton a été tronqué lors du stockage ou du transport

  occasionnelle

  Une colonne de base de données VARCHAR(255), une limite de taille des lignes de journal ou un copier-coller qui a perdu la fin peut couper le jeton de sorte qu’il reste moins de trois segments. Les jetons ES256 font environ 200 caractères ou plus ; les jetons RS256 sont bien plus longs.

• Ce n’est pas du tout un JWT

  occasionnelle

  Certains fournisseurs OAuth émettent des jetons d’accès opaques (des chaînes aléatoires) qui ne sont pas des JWT. Passer un access_token opaque de Google ou de GitHub à jwt.verify() échoue ici : seul l’id_token (OpenID Connect) est à coup sûr un JWT.

Comment corriger l’erreur

1. 1.

   Retirer le préfixe de schéma avant la vérification

   Ne prenez que la partie jeton de l’en-tête Authorization, et prévoyez le cas d’un en-tête absent pour échouer avec un 401 explicite plutôt qu’avec « jwt malformed ».

   const auth = req.headers.authorization ?? "";
   const [scheme, token] = auth.split(" ");
   if (scheme !== "Bearer" || !token) {
     return res.status(401).json({ error: "missing bearer token" });
   }
   jwt.verify(token, publicKey, { algorithms: ["ES256"] });

2. 2.

   Journaliser la valeur brute et compter ses segments

   Une seule ligne de journal vous indique s’il s’agit d’un préfixe, d’une troncature ou de la mauvaise variable. Un JWS a exactement 3 segments ; un JWE en a 5 ; tout le reste n’est pas un jeton.

   console.log(JSON.stringify(token).slice(0, 80));
   console.log("segments:", String(token).split(".").length); // must be 3

3. 3.

   Vérifier ce que contient réellement le jeton

   Collez la chaîne dans le débogueur JWT ci-dessous : il décode l’en-tête et les claims localement et vous indique précisément quel segment est défectueux – ou que la chaîne n’est pas du tout un JWT.

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