Wie ich JWT Issuer Validation und iss Mismatches debugge

Wenn ein JWT strukturell korrekt aussieht, aber invalid issuer, issuer mismatch oder weiter 401 liefert, behandle ich iss als Problem der Vertrauensgrenze.

Meine Frage ist nicht nur:

Welcher String steht in iss?

Sondern:

Ist das exakt der Issuer, dem meine Anwendung vertraut, und wurde das Token mit Schlüsseln verifiziert, die wirklich zu diesem Issuer gehören?

1. iss lesen, aber noch nicht vertrauen

{
  "iss": "https://login.example.com/",
  "sub": "user_123",
  "aud": "api://orders",
  "exp": 1789203600
}

Vor der Signaturprüfung ist auch dieser Wert eine nicht vertrauenswürdige Eingabe. Eine bekannte URL allein reicht nicht.

2. Erwarteten Issuer aus der Resource-Server-Konfiguration bestimmen

Ich suche einen autoritativen Wert:

https://login.example.com/

und vergleiche exakt.

Diese Werte können unterschiedlich sein:

https://login.example.com
https://login.example.com/
https://login.example.com/tenant-a
https://login.example.com/tenant-b

Ich normalisiere Issuer-Strings nicht eigenmächtig, wenn das Protokoll exakte Übereinstimmung erwartet.

3. Dev/Staging/Prod-Verwechslungen ausschließen

{
  "iss": "https://login.dev.example.com/",
  "aud": "api://orders-dev"
}

kann in Produktion gleichzeitig Issuer Mismatch, Audience Mismatch, kid not found und Signaturfehler erzeugen.

Wenn mehrere dieser Fehler zusammen auftreten, untersuche ich die Umgebungskonfiguration vor dem Kryptografiecode.

4. Vertrauenswürdigen Schlüsselsatz an den Issuer binden

Mit RFC-8414-Metadata möchte ich folgenden Pfad:

Anwendung vertraut Issuer A
        ↓
Metadata von Issuer A
        ↓
jwks_uri von Issuer A
        ↓
JWKS von Issuer A
        ↓
ausgewählter Schlüssel
        ↓
Signatur verifiziert

Nicht: Das unverifizierte Token behauptet einen Issuer und bestimmt danach selbst eine beliebige Schlüssel-URL.

Der JWKS Validator folgt deshalb keiner jku/x5u-URL automatisch.

5. Signatur prüfen, bevor ich Issuer-abhängigen Claims vertraue

Ist kid vorhanden, wähle ich den Schlüssel aus dem JWKS des vertrauenswürdigen Issuers und verifiziere die Signatur.

Fehlt der Schlüssel, gehe ich zur JWT-kid-Anleitung. Ist der Schlüssel vorhanden und die Signatur fehlerhaft, nutze ich die Anleitung für ungültige Signaturen.

Die Issuer-Konfiguration sagt mir, welche Schlüssel vertrauenswürdig sind; diese Schlüssel authentifizieren anschließend den signierten iss-Claim.

6. Gültige Signatur + falscher Issuer bleibt ein Reject

Signatur gültig ✓
iss == erwartet ✕

ist kein akzeptables Token.

Eine Plattform kann viele Tenants oder Token-Profile mit gültigen Schlüsseln haben.

7. Issuer und Audience getrennt halten

• iss: Wer hat ausgestellt?
• aud: Für wen?

Nach erfolgreichem Issuer-Check prüfe ich Audience, Zeit, Token-Typ und Berechtigungen.

8. Multi-Tenant vorsichtig modellieren

Ich frage:

• Hat jeder Tenant einen eigenen Issuer?
• Erwartet die Library Tenant-spezifische Issuer?
• Werden Schlüssel geteilt?
• Unterstützt die API bewusst mehrere Issuer?
• Kommt die Issuer-Auswahl aus vertrauenswürdiger Konfiguration?

Ein breites „alles unter dieser Domain akzeptieren“ verwende ich nur, wenn das Sicherheitsmodell es explizit vorsieht.

9. Slash, Path, Scheme und Whitespace vergleichen

Trailing Slash, Tenant-Pfad, https/http, Hostname und alte Migrations-URLs sind häufige Ursachen scheinbar identischer Issuer.

10. Konfiguration, Metadata und JWT vergleichen

konfigurierter issuer
metadata issuer
JWT iss

Wenn diese drei Punkte nicht zusammenpassen, habe ich meist ein Discovery- oder Konfigurationsproblem.

Meine Issuer-Checkliste

1. JWT dekodieren, iss, kid, alg, aud lesen.
2. Exakten erwarteten Issuer bestimmen.
3. Umgebung und Tenant prüfen.
4. Metadata/JWKS aus vertrauenswürdiger Konfiguration beziehen.
5. kid in diesem JWKS auswählen.
6. Signatur mit einem Schlüssel des Issuers verifizieren.
7. Authentifiziertes iss exakt vergleichen.
8. Danach aud, exp, nbf, Token-Profil prüfen.
9. Server-Logs lesen.
10. Vertrauenspfad korrigieren, Issuer-Validierung nicht abschalten.

Issuer Validation bedeutet für mich nicht „sieht die URL bekannt aus?“, sondern wurde das JWT mit Schlüsseln des bewusst vertrauten Issuers authentifiziert und stimmt der signierte Issuer-Identifier exakt mit diesem Vertrauensanker überein?