12. Matrice de tests et preuves JWT

Comprendre le mécanisme

Une revue de validation doit couvrir plus que le cas nominal : signature invalide, algorithme interdit, clé inconnue, issuer ou audience inattendus, temps limites et profil croisé. Le code d’erreur public doit rester adapté au contrat sans détailler les secrets de configuration. Les diagnostics internes peuvent nommer une catégorie de refus, une version et un identifiant de corrélation non sensible.

Raisonner et vérifier

Organisez les tests avec une horloge injectée, des paires de clés de laboratoire et des fixtures indépendantes du fournisseur réel. Chaque test négatif doit vérifier le refus mais aussi l’absence de mutation ou d’appel aval. Ajoutez un test nominal pour chaque profil supporté et une simulation d’incident. Une réussite de QCM indique une préparation conceptuelle ; seule une vérification de l’implémentation et de son périmètre établit les propriétés du service.

Profils croisés

Une matrice doit inclure des profils croisés. Les règles de destination et d’usage demandent leurs propres cas. Présentez un token interne valide à une API qui exige un access token. Cette fixture vérifie le rejet de substitution ; une simple chaîne aléatoire ne couvre pas la même propriété.

Temps reproductible

Une horloge injectée stabilise le test exp. Le contrôle du temps élimine cette incertitude. Injectez une horloge et vérifiez les bornes temporelles précises, tolérance comprise. Un token choisi pour expirer demain rendrait le test dépendant du calendrier et finirait par produire une panne sans changement de code.

Clés factices

Les clés de tests doivent être sans usage réel. Le test ne doit pas exposer une capacité réelle. Générez ou conservez des clés publiques de laboratoire sans usage réel. Les artefacts et captures de test doivent être partageables sans exposer une capacité valable sur un environnement client.

Non-effet

Un refus doit précéder les effets métier. La réponse seule ne prouve pas l’absence d’effet. Un statut 401 obtenu après une écriture ne protège pas le métier. Vérifiez état de base, queue et appels prestataire afin de démontrer que le refus coupe effectivement le traitement sensible.

Succès nécessaire

Un cas nominal évite de tester uniquement le rejet général. Il doit aussi accepter le profil autorisé. Gardez au moins un token conforme par profil attendu. Cette preuve distingue une politique fonctionnelle d’un composant qui refuse systématiquement toutes les demandes et ferait réussir les seuls tests négatifs.

Types hostiles

Les mauvais types de claims doivent être testés. Les valeurs doivent respecter le contrat attendu. Essayez aud tableau ou chaîne selon le contrat, exp sous forme de texte et claims obligatoires absents. Le validateur doit appliquer le profil sans conversion qui élargit silencieusement les valeurs admises.

Catégories de refus

Une catégorie de refus aide le diagnostic sans token brut. L’enquête peut rester minimisée. Un événement audience_invalid avec version et corrélation aide à diagnostiquer sans conserver le token. Contrôlez aussi que messages d’exception et outils de tracing ne recopient pas automatiquement l’entrée entière.

Versions

Les versions doivent accompagner les résultats. Une mise à jour peut changer le comportement. Associez résultats aux versions de bibliothèque, runtime et configuration. Une preuve d’ancienne release ne se transfère pas automatiquement après modification d’options, d’algorithmes ou de distribution des clés.

Incident simulé

Une simulation doit couvrir l’incident de clé. Les procédures de retrait demandent des scénarios dédiés. Révoquez une clé de test et mesurez quand chaque consommateur refuse ses signatures. Ajoutez cache ancien et fournisseur indisponible pour vérifier que la procédure tient dans les conditions qu’elle annonce.

Compétence et production

Un QCM ne remplace pas une vérification d’implémentation. L’évaluation de connaissances a un périmètre différent. Réussir un QCM mesure une compréhension locale. Il faut encore vérifier l’implémentation, ses configurations réelles et ses limites opérationnelles ; conservez les lacunes connues dans le dossier de revue.

Atelier guidé : lire, expliquer et vérifier le code

// Pseudocode de test :
response = callApi(tokenWithWrongAudience)
assert response.status == 401
// Aucune assertion sur la base ni les appels aval.

Le test proposé vérifie le statut mais ne regarde aucun effet aval. Ajoutez des assertions de base et des espions sur les appels sensibles. Utilisez un token signé avec mauvaise audience pour isoler cette règle, puis un token nominal pour prouver que le service accepte toujours le profil attendu.

L’expiration ne prouve pas l’état métier. Un refus peut arriver après un effet si l’ordre est incorrect. Le statut ne restaure pas un état déjà écrit. Le test doit observer la propriété attendue.

Travail pratique : Construisez une matrice de douze cas et automatisez au moins une limite temporelle et une substitution de profil.

Critères de correction : Fixez l’horloge et les données initiales. Comparez réponse, absence d’écriture et appels aval. Conservez versions, configuration publique et résultats expurgés ; indiquez explicitement les menaces non couvertes.