Unable to find a signing key that matches '2026-10-rotated'

Der Wert in Anführungszeichen ist der `kid` des Tokens (`'undefined'`, wenn der Header keinen hat). Über `jwt.verify()` mit einem Callback bekommt der Text das Präfix „error in secret or public key callback: “. Ein Token ohne `kid` scheitert an einem Satz mit mehreren Schlüsseln mit „No KID specified and JWKS endpoint returned more than 1 key“.

jwks-rsa (Node.js) — SigningKeyNotFoundError, often wrapped by jsonwebtoken or express-jwt

Was der Fehler bedeutet

jwks-rsa hat den Schlüsselsatz heruntergeladen, aber keiner der verwendbaren Signaturschlüssel darin hat den `kid` aus dem Header des Tokens (der Wert in Anführungszeichen). Das Token kann völlig gültig sein – dem Prüfer fehlt nur der Schlüssel, mit dem es signiert wurde. Wird jwks-rsa über den Schlüssel-Callback von jsonwebtoken verwendet, steht vor der Meldung das Präfix „error in secret or public key callback:“.

Warum der Fehler auftritt

• Schlüsselrotation und ein zwischengespeicherter Schlüsselsatz

  häufig

  Der Provider signiert inzwischen mit einem neuen Schlüssel. jwks-rsa ruft den Satz bei einem unbekannten `kid` neu ab, aber nur, wenn Caching und Rate Limiting das zulassen; ein Client mit sehr langem Cache oder eine manuelle Kopie der Schlüssel scheitert weiter bis zum Neustart.

• Die JWKS-URL gehört zu einem anderen Mandanten oder einer anderen Umgebung

  häufig

  Auth0-Mandanten, Cognito-User-Pools, Entra-ID-Mandanten und Keycloak-Realms haben jeweils einen eigenen Schlüsselsatz. Eine `jwksUri` aus dem Staging in der Produktion liefert Schlüssel mit gültig aussehenden, aber anderen Werten für `kid`.

• Der passende Schlüssel wurde herausgefiltert

  gelegentlich

  jwks-rsa berücksichtigt nur Schlüssel, bei denen `use` fehlt oder `"sig"` ist, deren `kty` RSA, EC oder OKP ist und die es als öffentliche Schlüssel importieren kann. Ein mit `use: "enc"` veröffentlichter Schlüssel oder ein fehlerhafter JWK wird stillschweigend übersprungen, selbst wenn sein `kid` passt.

• Das Token wurde von einem anderen Provider ausgestellt

  gelegentlich

  Tokens eines anderen Identity Providers (oder ein Token, das du lokal für Tests ausgestellt hast) verweisen auf Schlüssel, die dieser Provider nie veröffentlicht hat. Prüfe `iss` in der Payload, bevor du mit der Fehlersuche bei den Schlüsseln beginnst.

So behebst du den Fehler

1. 1.

   Veröffentlichte kid-Werte auflisten

   Dekodiere den Header des Tokens und vergleiche seinen `kid` mit den Schlüsseln unter deiner `jwksUri`. Steht der `kid` dort, aber der Fehler bleibt, wird der Schlüssel herausgefiltert – sieh dir sein `use` und `kty` an.

   # kids the provider publishes (jwks-rsa ignores keys with use "enc" and non RSA/EC/OKP keys)
   curl -s https://tenant.example.com/.well-known/jwks.json | jq '.keys[] | {kid, kty, use, alg}'

2. 2.

   Einen einzigen Client mit Cache und Rate Limiting anlegen

   Ein Client auf Modulebene mit Caching ruft den Satz neu ab, wenn ein neuer `kid` auftaucht, und schützt den Provider vor einer Flut von Anfragen, wenn Angreifer zufällige Werte für `kid` senden.

   import jwksRsa from "jwks-rsa";
   
   // One client per process; unknown kids trigger a refetch, bounded by the rate limit.
   export const jwksClient = jwksRsa({
     jwksUri: "https://tenant.example.com/.well-known/jwks.json",
     cache: true,
     cacheMaxAge: 10 * 60 * 1000,
     rateLimit: true,
     jwksRequestsPerMinute: 10,
   });

← Gesamte Signaturfehler-Datenbank durchsuchen