"alg" (Algorithm) Header Parameter value not allowed

jose (JavaScript) — JOSEAlgNotAllowed, code ERR_JOSE_ALG_NOT_ALLOWED

Was der Fehler bedeutet

Der Header alg des Tokens nennt einen Algorithmus, der nicht in der Allowlist der Algorithmen steht, die du jwtVerify übergeben hast. jose lehnt ab, bevor überhaupt eine kryptografische Operation läuft. Diese Sperre ist Absicht: Der Header alg ist eine Eingabe, die ein Angreifer frei wählen kann, und den Algorithmus muss die prüfende Seite festlegen – nicht das Token.

Warum der Fehler auftritt

• Allowlist passt nicht mehr zum Aussteller

  häufig

  Der Aussteller ist von RS256 auf ES256 umgestiegen (oder hat einen neuen Signaturschlüssel mit einem anderen Algorithmus hinzugefügt), während die prüfende Seite noch auf die alte Algorithmenfamilie festgelegt ist. Jedes neue Token scheitert, bis Allowlist und Schlüssel gemeinsam aktualisiert sind – und die Fehler beginnen genau in der Minute, in der der Aussteller umstellt. In den Logs ist das ein nützliches forensisches Indiz.

• Die Allowlist schreibt den Algorithmus anders

  gelegentlich

  Verglichen wird exakt und unter Beachtung der Groß- und Kleinschreibung mit dem JOSE-Namen: „es256“, „ECDSA“, „P-256“ oder „SHA256withECDSA“ in einer Konfigurationsdatei passen nie zu einem Header mit „ES256“. (Ein Schlüssel, der nicht zum Header passt – ein P-384-Schlüssel für ein ES256-Token, ein JWK mit abweichendem eigenem alg –, scheitert anders, nämlich mit einem TypeError, der den Schlüssel beschreibt.)

• Ein böswilliger oder falsch konfigurierter Client variiert alg

  selten

  Tokens, die mit alg: „none“ oder einem unerwarteten HS*-Wert ankommen, sind genau das, was diese Prüfung aufhalten soll. Tauchen fremde Algorithmen in den Logs auf, werte das als Sondierungsversuch und nicht als Bug, für den du eine Ausnahme schaffen solltest.

So behebst du den Fehler

1. 1.

   Allowlist, Schlüssel und Konfiguration des Ausstellers abgleichen

   Sieh dir den Header an und bring dann alle drei in Einklang. Akzeptiere während einer Migration vorübergehend beide Algorithmen, jeden mit seinem eigenen Schlüssel, ausgewählt über kid im JWKS.

   import { decodeProtectedHeader, jwtVerify } from "jose";
   
   console.log(decodeProtectedHeader(token)); // { alg: "ES256", kid: "..." }
   await jwtVerify(token, jwks, { algorithms: ["ES256"] });

2. 2.

   Allowlist so klein wie möglich halten

   Versuch nicht, diesen Fehler zu „beheben“, indem du jeden Algorithmus in die Liste aufnimmst. Ein Wert pro Token-Typ ist der sichere Endzustand; RFC 8725 (JWT Best Current Practices) sagt dasselbe.

   // good: exactly what your issuer signs with
   { algorithms: ["ES256"] }
   // bad: defeats the protection this error provides
   { algorithms: ["ES256", "RS256", "HS256", "PS256"] }

← Gesamte Signaturfehler-Datenbank durchsuchen