Comment je débogue la validation de l'issuer JWT et les erreurs iss

Quand un JWT paraît structurellement correct mais que l'API signale invalid issuer, issuer mismatch ou continue avec 401 après vérification de la signature, je traite iss comme un problème de limite de confiance.

Ma question n'est pas seulement « quelle valeur contient iss ? ». Je veux savoir :

Est-ce exactement l'issuer que mon application a choisi de faire confiance, et ai-je vérifié le JWT avec des clés qui appartiennent réellement à cet issuer ?

Étape 1 : lire iss sans encore lui faire confiance

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

Avant vérification de signature, un attaquant peut écrire n'importe quel issuer dans le payload.

Étape 2 : identifier l'issuer attendu

Je cherche la valeur de référence dans la configuration du resource server :

https://login.example.com/

Puis je compare exactement.

Ces valeurs peuvent être différentes :

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

Je n'applique pas de normalisation arbitraire si le protocole exige une correspondance exacte.

Étape 3 : éliminer les mélanges Dev/Staging/Prod

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

peut provoquer issuer mismatch, audience mismatch, kid not found et échec de signature simultanément en production.

Quand plusieurs erreurs apparaissent ensemble, je vérifie l'environnement avant le code cryptographique.

Étape 4 : lier les clés de confiance à l'issuer

Avec les metadata RFC 8414, je veux :

application fait confiance à issuer A
        ↓
metadata de issuer A
        ↓
jwks_uri de issuer A
        ↓
JWKS de issuer A
        ↓
clé sélectionnée
        ↓
signature vérifiée

Je ne veux pas qu'un token non vérifié fournisse lui-même la source de clés à faire confiance.

JWKS Validator ne suit donc pas automatiquement jku ou x5u.

Étape 5 : vérifier la signature avant de croire iss

Avec kid, je sélectionne une clé du JWKS lié à l'issuer de confiance puis je vérifie la signature.

Si la clé manque, j'utilise le guide JWT kid. Si elle existe mais que la signature échoue, j'utilise le guide sur les signatures invalides.

La configuration de l'issuer détermine quelles clés sont dignes de confiance ; ces clés authentifient ensuite le claim iss signé.

Étape 6 : signature valide + issuer incorrect reste un rejet

signature valide ✓
iss == attendu ✕

n'est pas acceptable.

Une plateforme peut avoir plusieurs tenants, issuers ou profils avec des signatures valides.

Étape 7 : ne pas confondre issuer et audience

• iss : qui a émis ?
• aud : pour qui ?

Après l'issuer, je continue avec audience, exp, nbf, type de token et permissions.

Étape 8 : multi-tenant avec une politique explicite

Je vérifie :

• issuer unique par tenant ;
• comportement de la bibliothèque ;
• clés partagées ou non ;
• liste des issuers volontairement pris en charge ;
• sélection basée sur une configuration de confiance.

Je n'accepte pas tout issuer sous un hostname large sans modèle de sécurité explicite.

Étape 9 : comparer slash, path, scheme et espaces

Trailing slash, tenant path, https, hostname et anciennes valeurs après migration sont des causes fréquentes.

Étape 10 : comparer trois sources

issuer configuré
issuer des metadata
JWT iss

Si elles divergent, je cherche d'abord un problème de discovery ou de configuration.

Ma checklist de validation de l'issuer

1. Décoder le JWT, lire iss, kid, alg, aud.
2. Identifier l'issuer attendu exact.
3. Vérifier environnement et tenant.
4. Obtenir metadata/JWKS via une configuration de confiance.
5. Sélectionner kid dans ce JWKS.
6. Vérifier la signature avec une clé de cet issuer.
7. Comparer exactement le iss authentifié.
8. Valider aud, exp, nbf et profil de token.
9. Lire les logs serveur.
10. Corriger la chaîne de confiance, sans désactiver la validation de l'issuer.

La validation de l'issuer ne consiste pas à reconnaître une URL familière. Elle consiste à authentifier le JWT avec les clés du bon issuer et à confirmer que l'issuer signé correspond exactement à la confiance configurée.