jwt malformed

Was der Fehler bedeutet

jwt.verify() von jsonwebtoken konnte das Token nicht einmal parsen: Der String lässt sich nicht in genau drei durch Punkte getrennte Segmente zerlegen. Die Signatur wurde nie geprüft – der String, den du übergeben hast, ist strukturell kein JWT. (Ein String, der zwar drei Segmente hat, dessen Header aber kein base64url-kodiertes JSON ist, scheitert einen Schritt später mit „invalid token“.)

Warum der Fehler auftritt

• Der Header Authorization wurde falsch zerlegt

  häufig

  Der Wert des Headers Authorization ist „Bearer eyJ...“, und der Code hat die falsche Hälfte davon behalten: auth.split(" ")[0] übergibt jwt.verify() das Schema „Bearer“ selbst, das überhaupt keine Punkte enthält. Übergibst du den ganzen String „Bearer eyJhbGci...“, scheitert das auf andere Weise – der String zerfällt trotzdem in drei Segmente, daher meldet jsonwebtoken „invalid token“, wenn sich das erste nicht dekodieren lässt.

• Die falsche Variable ist in verify() gelandet

  häufig

  Wo das Token stehen sollte, ist ein String gelandet, der kein Token ist: „undefined“ oder „null“ aus der Interpolation eines fehlenden Werts (ein Client sendet „Bearer null“, weil nichts gespeichert war, ein falsch geschriebenes req.headers.authorisation, ein fehlendes Cookie), „[object Object]“, weil die dekodierte Payload statt des rohen Tokens in einen String umgewandelt wurde, oder eine Benutzer-ID. Ein echtes undefined, null oder ein leerer String wird schon eine Prüfung früher abgefangen, mit „jwt must be provided“.

• Das Token wurde beim Speichern oder bei der Übertragung abgeschnitten

  gelegentlich

  Eine Datenbankspalte VARCHAR(255), eine Längenbegrenzung für Logzeilen oder Kopieren und Einfügen, bei dem das Ende verloren ging, kann das Token so kürzen, dass weniger als drei Segmente übrig bleiben. ES256-Tokens sind ~200+ Zeichen lang, RS256-Tokens deutlich länger.

• Der Wert ist überhaupt kein JWT

  gelegentlich

  Manche OAuth-Anbieter stellen opake Access Tokens (zufällige Strings) aus, die keine JWTs sind. Ein opakes access_token von Google/GitHub scheitert in jwt.verify() genau hier – nur das id_token (OpenID Connect) ist garantiert ein JWT.

So behebst du den Fehler

1. 1.

   Schema-Präfix vor der Prüfung entfernen

   Nimm nur den Token-Teil des Headers Authorization und fang einen fehlenden Header ab, damit du mit einem klaren 401 statt mit „jwt malformed“ abbrichst.

   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.

   Rohwert protokollieren und Segmente zählen

   Eine einzige Logzeile zeigt dir, ob du es mit einem Präfix, einem abgeschnittenen Wert oder der falschen Variable zu tun hast. Ein JWS hat genau 3 Segmente, ein JWE hat 5; alles andere ist kein Token.

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

3. 3.

   Prüfen, was das Token tatsächlich enthält

   Füge den String unten in den JWT-Debugger ein: Er dekodiert Header und Claims lokal und sagt dir genau, welches Segment defekt ist – oder dass der String überhaupt kein JWT ist.

← Gesamte Signaturfehler-Datenbank durchsuchen