02. JWS : intégrité et détenteurs de clés

Comprendre le mécanisme

JWS protège les données signées selon un algorithme et une clé. Une modification du contenu protégé doit faire échouer la vérification. Cela ne rend pas les données invisibles et ne vérifie pas à soi seul leurs droits métier. Avec un MAC symétrique, tout détenteur de la clé capable de vérifier peut aussi produire des MAC ; avec une signature asymétrique, la clé publique ne donne pas le pouvoir de signer.

Raisonner et vérifier

Choisissez la distribution des clés selon les rôles. Donner le secret de signature à chaque API de vérification élargit le périmètre capable d’émettre. Conservez la clé privée hors des bundles publics et des journaux. Une signature valide prouve un lien cryptographique avec une clé admise, puis le validateur doit encore lier cette clé à un émetteur, un usage et un profil.

Intégrité et visibilité

JWS peut protéger l’intégrité d’un contenu lisible. Une signature n’est pas un chiffrement. Une JWS compacte courante expose header et payload encodés. Ne placez pas un secret dans le payload en supposant que la signature le cache ; une politique de données doit précéder l’émission.

MAC partagé

Un MAC utilise une clé partagée. Le détenteur du secret possède les deux capacités. Avec une famille HMAC, la même capacité secrète sert à produire et vérifier la preuve. Distribuer cette clé à un consommateur lui donne donc aussi une capacité d’émission dans ce périmètre.

Asymétrie

La clé publique ne permet pas normalement de signer. Les capacités asymétriques sont séparées. Une signature asymétrique sépare clé privée de production et clé publique de vérification. Protégez la privée et maîtrisez la provenance de la publique ; la distinction ne supprime pas le besoin de distribution fiable.

Modification du contenu

Une donnée modifiée doit invalider sa preuve. La preuve est liée aux données protégées. Changez un claim sans recalculer une preuve autorisée et vérifiez le refus. Gardez aussi un cas correctement signé pour éviter qu’un validateur qui rejette tout semble satisfaire le test.

Clé liée à l’émetteur

Une clé admise doit être liée à un émetteur. L’authenticité cryptographique doit rejoindre un contrat de confiance. Une signature mathématiquement valide avec une clé choisie par l’attaquant n’établit pas le fournisseur attendu. Sélectionnez la clé dans un ensemble de confiance lié au contrat de cet émetteur.

Destination

L’audience doit être validée selon le profil. La destination reste une exigence distincte. Un token destiné à stock-api peut être signé par la bonne autorité sans convenir à reservation-api. La validation d’audience empêche cette réutilisation entre consommateurs qui ne partagent pas le même contrat.

Clé privée

La clé privée doit rester hors des assets publics. Cela exposerait le pouvoir de signature. Une clé privée dans public ou dans un bundle frontend devient récupérable. Vérifiez aussi images, exports et sauvegardes ; limiter la route principale ne retire pas les autres copies de la capacité.

Ordre des décisions

La vérification doit précéder l’autorisation métier. Les effets interdits peuvent déjà avoir eu lieu. Le métier ne doit pas utiliser les claims avant la réussite des vérifications. Une vérification tardive peut produire un refus HTTP après un effet déjà commis, ce qui ne rétablit pas l’état initial.

Politique d’algorithme

Le choix d’algorithme doit suivre une politique fermée. La politique doit précéder la donnée hostile. Le validateur fixe les algorithmes autorisés et leur compatibilité avec les clés. Le champ alg reçu décrit une demande à contrôler, pas une instruction donnant au porteur le choix de la politique.

Ancien message valide

Une preuve valide ne prouve pas la nouveauté du message. La fraîcheur demande d’autres éléments du profil. Une signature reste valide lors d’un rejeu inchangé. Durée, état de retrait et éventuelle déduplication dépendent du profil et de la nature de l’opération ; la preuve cryptographique seule ne les remplace pas.

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

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJsYWIifQ.signature-de-laboratoire

Hypothèse : la signature réelle serait validée par une bibliothèque.
Cet exemple n’est pas un token utilisable.

L’exemple est une représentation pédagogique, pas un token utilisable. Même en supposant sa preuve réelle vérifiée, son contenu peut être décodé sans secret. Expliquez séparément intégrité, authenticité dans le modèle de clés et confidentialité, puis identifiez les contrôles de profil et de permission encore nécessaires.

L’encodage est réversible sans clé. Le nombre de segments n’apporte pas cette garantie. Signature et confidentialité ont des objectifs distincts. La propriété d’intégrité ne rend pas secret le contenu.

Travail pratique : Distribuez uniquement la clé publique à un validateur de laboratoire et testez contenu modifié, autre clé et jeton valide.

Critères de correction : Les deux cas altérés sont refusés. Vérifiez ensuite qu’un jeton correctement signé mais pour une autre API est également refusé par le profil.