Wie ich JWT kid und die JWKS-Schlüsselauswahl debugge

Bei kid not found, einer unbekannten Key ID oder Signaturproblemen nach einer Rotation schaue ich zuerst in den JWT-Header. kid hilft dem Verifier, einen Kandidaten aus einem vertrauenswürdigen JWK Set auszuwählen.

Mein Ziel ist nicht, irgendeinen Schlüssel zu finden, der mathematisch passt. Ich möchte belegen, dass ich den richtigen Schlüssel aus der richtigen, an den Issuer gebundenen Quelle mit einem ausdrücklich erlaubten Algorithmus ausgewählt habe.

Mit JWT und JWKS starte ich im JWKS Validator.

1. kid aus dem Header lesen

{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "2026-09-key-03"
}

RFC 7515 und RFC 7517 definieren kid als Key ID. Besonders bei einer Rotation kann es bei der Schlüsselauswahl helfen.

Für mich ist kid ein Auswahlhinweis, kein Vertrauensbeweis. Ein nicht verifiziertes Token kann jeden beliebigen Wert eintragen.

2. Im vertrauenswürdigen JWKS suchen

{
  "keys": [
    { "kty": "RSA", "kid": "2026-09-key-03", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" },
    { "kty": "RSA", "kid": "2026-06-key-02", "use": "sig", "alg": "RS256", "n": "...", "e": "AQAB" }
  ]
}

Ich suche nicht im Web nach demselben kid. Key IDs sind nicht global eindeutig.

Mein Vertrauenspfad:

konfigurierter Issuer
      ↓
vertrauenswürdige Metadata
      ↓
vertrauenswürdige jwks_uri
      ↓
JWK Set
      ↓
kid-Treffer

3. Fehlendes kid ist nicht automatisch ungültig

Nicht jedes signierte JWT muss kid enthalten.

Ist im vertrauenswürdigen JWKS genau ein kompatibler Verifikationsschlüssel vorhanden, kann die Auswahl nach Policy eindeutig sein.

Sind mehrere kompatible Schlüssel vorhanden und fehlt kid, behandle ich die Auswahl ohne weitere deterministische Regel als mehrdeutig. Ich lasse den Verifier nicht blind alle Schlüssel ausprobieren, bis einer funktioniert.

Der JWKS Validator verhält sich entsprechend konservativ.

4. alg, kty, use, key_ops prüfen

Ein kid-Treffer reicht nicht.

Ich kontrolliere:

• JWT alg;
• JWK kty;
• JWK alg wenn vorhanden;
• use wenn vorhanden;
• key_ops wenn vorhanden.

RS256 braucht einen RSA-Verifikationsschlüssel; ES256 einen passenden EC-Schlüssel. use: "enc" ist kein Schlüssel zur Signaturprüfung.

5. kid not found führt oft zu Rotation und Cache

Typisch:

Issuer veröffentlicht Schlüssel A
→ Tokens nutzen A
→ Issuer veröffentlicht B
→ neue Tokens nutzen kid B
→ Verifier cached nur A

Dann prüfe ich:

1. Veröffentlicht der Issuer B aktuell?
2. Wie lang ist die JWKS-Cache-TTL?
3. Gibt es einen Refresh bei fehlendem kid?
4. Nutze ich vielleicht Dev- oder falsche Tenant-Metadata?

Ich ersetze Caching nicht durch einen Netzwerkaufruf pro Token. Ich nutze einen kontrollierten Refresh-Mechanismus.

6. Umgebung und Tenant prüfen

JWT iss:    https://login.dev.example.com/
API trusts: https://login.example.com/

macht ein fehlendes kid sehr plausibel.

Deshalb frage ich nicht nur „Wo ist der Schlüssel?“, sondern auch „Stammt dieses Token überhaupt vom vorgesehenen Issuer?“.

7. jku/x5u nicht automatisch vertrauen

Token-gesteuerte URLs sind nicht vertrauenswürdige Eingaben. RFC 8725 warnt vor SSRF- und Vertrauensproblemen, wenn Verifier beliebigen URLs folgen.

Der JWKS Validator lädt deshalb nur eine JWKS-URL, die ich ausdrücklich angebe.

8. kid gefunden ist nicht gleich Signatur verifiziert

kid gefunden          ✓
Algorithmus kompatibel ✓
Schlüssel für Signatur ✓
Signatur verifiziert   ✓ / ✕

Erst der letzte Schritt ist die kryptografische Prüfung. Bei einem Fehler gehe ich zur Anleitung für ungültige Signaturen.

9. Danach Claims validieren

Nach erfolgreicher Signatur prüfe ich iss, aud, exp, nbf, Token-Typ sowie Scopes/Roles.

Ein korrekt signiertes Token kann für eine andere API oder ein anderes Token-Profil gedacht sein.

Meine kid-Checkliste

1. JWT dekodieren, alg, kid, iss lesen.
2. Vertrauenswürdigen Issuer bestimmen.
3. JWKS aus dessen vertrauenswürdiger Konfiguration beziehen.
4. Exakten kid-Treffer suchen.
5. kty, alg, use, key_ops prüfen.
6. Bei fehlendem Schlüssel Rotation und Cache untersuchen.
7. Umgebung und Tenant kontrollieren.
8. Keine beliebigen Token-gesteuerten Schlüssel-URLs vertrauen.
9. Signatur mit der ausgewählten JWK verifizieren.
10. Danach Issuer, Audience und Zeit validieren.

Die zentrale Idee bleibt: kid hilft mir, einen Schlüssel zu finden. Es erklärt nicht, warum dieser Schlüssel vertrauenswürdig sein sollte.