invalid signature

Was der Fehler bedeutet

Das Token ließ sich problemlos parsen und seine Struktur ist gültig, aber die kryptografische Prüfung ist fehlgeschlagen: Die Signatur über header.payload lässt sich mit dem von dir übergebenen Schlüssel nicht bestätigen. Entweder ist es nicht der Schlüssel, mit dem das Token signiert wurde, oder die signierten Bytes haben sich nach dem Signieren verändert.

Warum der Fehler auftritt

• Prüfung mit dem falschen Schlüssel

  häufig

  Mit Abstand der häufigste Fall: In der Umgebung liegt ein anderer Schlüssel als der, den der Aussteller verwendet hat – ein veralteter öffentlicher Schlüssel nach einer Rotation, ein Staging-Schlüssel gegen Produktions-Tokens oder ein nicht passender kid im JWKS, wenn die prüfende Seite auf einen Schlüssel festgelegt ist, während der Aussteller mit einem anderen signiert.

• Ein selbst gebauter Signierer hat die falschen Bytes signiert

  gelegentlich

  Code, der Tokens von Hand baut, muss die ASCII-Bytes von base64url(header).base64url(payload) mit SHA-256 signieren und das rohe r‖s mit 64 Byte ausgeben, das RFC 7518 für ES256 vorschreibt. Das Signieren des JSON selbst, von Segmenten in base64 mit Standardalphabet oder eines SHA-384-Digests unter einem ES256-Header ergibt eine formal korrekte Signatur, die sich nie bestätigen lässt. (Eine DER-kodierte Signatur wird schon vor der Prüfung abgelehnt, mit „"ES256" signatures must be "64" bytes“, und ein durch eine Umgebungsvariable verstümmeltes PEM wird gar nicht erst als Schlüssel akzeptiert: Es scheitert mit „secretOrPublicKey must be an asymmetric key when using ES256“.)

• Das Token wurde nach dem Signieren verändert

  gelegentlich

  Ein Proxy, ein Logger oder ein Client hat das JSON der Payload neu serialisiert oder darin Zeichen verändert. Schon ein einziges geändertes Zeichen in Header oder Payload macht die Signatur ungültig – genau dafür wird signiert. (An ein Segment angehängtes Base64-Padding scheitert einen Schritt früher, mit „invalid token“; ein abgeschnittenes Token scheitert mit „jwt malformed“ oder einem Fehler zur Signaturlänge.)

So behebst du den Fehler

1. 1.

   Fingerabdruck des Schlüssels auf beiden Seiten vergleichen

   Bilde den Hash des öffentlichen Schlüssels, den die prüfende Seite tatsächlich geladen hat, und vergleiche ihn mit dem des Ausstellers. Weicht der Fingerabdruck ab, ist der Schlüssel veraltet oder falsch – mit Abstand die häufigste Ursache –, und die Suche ist in einem Schritt beendet.

   import { createHash, createPublicKey } from "node:crypto";
   
   // Run on the verifier, and on the issuer with its signing key: the outputs must match.
   const spki = createPublicKey(process.env.JWT_PUBLIC_KEY).export({ type: "spki", format: "der" });
   console.log(createHash("sha256").update(spki).digest("hex"));

2. 2.

   kid des Tokens mit dem Prüfschlüssel abgleichen

   Dekodiere den Header ohne Prüfung und vergleiche seinen kid mit dem Schlüssel, den du hast. Veröffentlicht der Aussteller ein JWKS, ermittle den Schlüssel per kid, statt einen fest im Code zu hinterlegen.

   const { header } = jwt.decode(token, { complete: true });
   console.log(header.kid, header.alg); // compare with your JWKS / configured key

3. 3.

   Den Debugger die Abweichung benennen lassen

   Füge Token und öffentlichen Schlüssel in den JWT-Debugger ein: Er prüft ES256/ES384/ES512 lokal und unterscheidet zwischen falschem Schlüssel, manipulierter Payload und fehlerhafter Kodierung der Signatur, statt nur einen Boolean zu liefern.

← Gesamte Signaturfehler-Datenbank durchsuchen