05. Algorithmes imposés et profils disjoints

Comprendre le mécanisme

L’en-tête JOSE arrive de l’extérieur. Le validateur doit vérifier que l’algorithme reçu appartient à une liste autorisée pour cette clé et cet usage. Il ne doit pas utiliser indifféremment des octets de clé publique comme secret MAC. L’acceptation d’un algorithme non signé ne doit jamais apparaître accidentellement dans un profil qui exige une signature.

Raisonner et vérifier

Séparez les validateurs de contextes différents : accès API, identité utilisateur et message interne peuvent avoir des règles incompatibles. Un type explicite peut aider à distinguer les profils lorsque leur spécification le prévoit, avec un contrôle effectif côté réception. Préférez les mécanismes de la bibliothèque aux branches manuelles sur alg. Testez des clés et types incohérents même lorsque la syntaxe du token est correcte.

Politique fermée

Le serveur fixe les algorithmes admis. L’entrée non fiable ne définit pas la politique. Une liste telle que RS256 est choisie côté validateur. Le porteur ne peut pas obtenir none ou une famille MAC en modifiant le header ; toute valeur hors contrat doit être rejetée.

Compatibilité de clé

La clé doit être compatible avec l’algorithme. La confusion de familles doit être évitée. Associez chaque clé à son type, son algorithme et son usage. Une bibliothèque polyvalente ne doit pas traiter opportunément les octets d’une clé publique comme un secret MAC pour un autre profil.

Signature exigée

Un profil signé doit refuser une absence de signature. La signature requise ne peut être retirée par le message. Un profil signé refuse l’absence de preuve même si le JSON est correctement formé. Testez explicitement le cas non signé afin de vérifier qu’un mode de compatibilité ne contourne pas cette exigence.

Type explicite

Un type explicite doit être vérifié lorsqu’il est requis. La déclaration doit participer à la décision. Lorsque le profil exige typ, comparez sa valeur attendue. Cette information contribue à séparer les usages, mais n’établit une confiance que lorsqu’elle fait partie des données protégées et validées.

Profils distincts

Les validateurs de profils différents peuvent devoir être séparés. Les audiences et règles peuvent être incompatibles. Un jeton d’accès et un message interne peuvent partager des noms de claims. Séparez leurs validateurs ou leurs configurations de façon à empêcher une substitution fondée sur cette ressemblance superficielle.

Usage et clé

La politique doit lier usage et clé. La possession de paramètres ne rend pas chaque usage légitime. Une clé admise pour un échange interne ne devient pas automatiquement valable pour un login utilisateur. Définissez la matrice émetteur, destinataire, type de token et ensemble de clés autorisé.

Cas nominal

Un test nominal doit accompagner les refus. Il doit reconnaître les entrées conformes au contrat. Un validateur qui rejette tout fait réussir tous les tests négatifs. Gardez une fixture valide pour chaque profil autorisé afin de prouver que la politique reste utilisable.

Toutes les opérations

La bibliothèque doit vérifier les opérations requises. Lire la structure ne vérifie pas la preuve. Une composition peut exiger vérification de signature, déchiffrement et contrôle de claims. Vérifiez que l’API de bibliothèque choisie exécute effectivement l’ensemble attendu avant de produire un objet de confiance.

Mises à jour

Les mises à jour de bibliothèque demandent une revue ciblée. L’outil ne choisit pas automatiquement toutes les règles métier. Relisez changements de comportement, défauts d’options et avis de sécurité de la bibliothèque. Rejouez surtout les tests de confusion de profil et d’algorithme sur la version réellement déployée.

Avant les effets

Les décisions doivent être appliquées avant les effets. L’ordre des contrôles détermine l’absence d’effet interdit. Ne confiez les données au handler métier qu’après validation. Les traces privées peuvent décrire le refus, mais aucune réservation, émission de message ou modification de droit ne doit précéder la décision.

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

<?php
declare(strict_types=1);
$allowed = ['RS256'];
$received = 'none';
echo in_array($received, $allowed, true) ? 'allowed' : 'rejected';

Le tableau autorise uniquement RS256 et la valeur reçue est none ; in_array en mode strict retourne donc faux. Ce contrôle illustre une liste fermée, sans implémenter à lui seul un validateur JWT complet. Ajoutez ensuite la sélection de clé et les contrôles cryptographiques et de claims requis.

none n’appartient pas à la liste fermée. Le message ne peut élargir la politique. Le code ne génère pas de clé. Ce test de politique n’exécute pas la cryptographie.

Travail pratique : Dans un laboratoire, essayez un token sans signature, un algorithme hors liste et un type destiné à un autre flux.

Critères de correction : Les trois refusent avant l’autorisation métier. Conservez une fixture nominale pour éviter de créer un validateur qui rejette tout sans distinguer les cas.