JWT, JWS et JWE — architecture et validation avancées

Comprendre le mécanisme

Un JWT transporte un ensemble de claims selon un profil. Sa sérialisation ne rend pas les affirmations fiables : un texte décodé peut provenir d’un appelant hostile. Dans la forme compacte signée courante, les segments utilisent base64url, qui représente des octets sans fournir de confidentialité. Les claims enregistrés ne sont pas tous obligatoires dans le format générique ; le profil applicatif doit préciser présence, types et règles.

Raisonner et vérifier

Traitez tout résultat de parsing comme non authentifié tant que les vérifications du profil ne sont pas terminées. Ne sélectionnez pas un compte ou une permission sur un payload simplement décodé. Le parseur doit borner taille et profondeur et refuser les structures ambiguës selon la bibliothèque. Établissez une séparation claire entre données reçues, jeton validé et acteur autorisé.

Décodage sans confiance

Décoder un payload ne vérifie pas sa signature. Le parsing ne crée pas de relation de confiance. Un attaquant peut écrire lui-même un JSON avec role=admin et l’encoder. Tant que la validation de preuve et de profil n’a pas réussi, ne transmettez pas ces valeurs au contrôle de permissions.

Base64url

Base64url est réversible sans secret. La représentation n’apporte pas de confidentialité. Le codage permet de transporter des octets avec un alphabet adapté aux URL. Il ne demande aucune clé pour être inversé ; le payload d’une JWS courante reste donc lisible pour son porteur.

Profil explicite

Le profil impose les claims nécessaires. Les exigences dépendent aussi du profil consommateur. JWT est un format général. Votre contrat précise champs obligatoires, types, émetteur, audience et temporalité ; la présence de noms enregistrés ne rend pas tous ces champs obligatoires dans tout usage.

Avant validation

Les données parsées restent non fiables avant validation. La décision doit attendre les vérifications requises. Le parseur peut lire des champs nécessaires à une sélection contrôlée, mais ne doit pas leur accorder une confiance générale. Gardez une distinction claire entre objet parsé et objet validé utilisable par le métier.

Budgets d’entrée

La taille du token doit être bornée. Le parsing et les calculs consomment des ressources. Limitez taille et complexité avant parsing ou vérification coûteuse. Une signature incorrecte sur une entrée énorme peut tout de même consommer mémoire et CPU avant son rejet final.

Bibliothèque maintenue

La signature doit être vérifiée par une bibliothèque adaptée. La forme n’établit pas la propriété cryptographique. Évitez d’implémenter cryptographie et validation JOSE par découpage de chaînes. Configurez une bibliothèque adaptée au profil, puis vérifiez ses options et ses refus avec des fixtures sans secrets réels.

Acteur et permission

Le modèle doit distinguer acteur et droits. L’identité ne fournit pas une permission universelle. sub indique un sujet dans le contexte de l’émetteur ; il ne prouve pas la propriété de chaque facture. Après validation du jeton, appliquez les règles de tenant et de ressource.

Signé ou chiffré

Un JWT peut être signé ou chiffré selon son profil. Le format n’impose pas une protection unique. Les formes JWS et JWE répondent à des propriétés différentes. Le contrat doit annoncer ce qu’il attend ; reconnaître un nombre de segments n’authentifie pas le contenu et ne prouve pas sa confidentialité.

Types des claims

Les types des claims doivent être vérifiés. La valeur doit respecter type et règles du profil. Un exp sous forme de tableau ne doit pas être converti opportunément en nombre. Vérifiez les types prescrits et le domaine des valeurs avant de comparer l’horloge ou d’interpréter une audience.

Refus sans effet

Les cas malformés doivent échouer sans effet métier. Le contrôle doit précéder les effets autorisés. Testez segments manquants, JSON invalide et valeurs hors contrat. Chaque échec doit arriver avant l’écriture métier, avec une réponse publique maîtrisée et sans journaliser le token brut.

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

{"sub":"lab-user","role":"admin","exp":4102444800}

État de l’exercice : JSON seulement décodé.
Signature, issuer et audience : non vérifiés.

Le JSON montré est seulement décodé. La valeur admin doit rester une affirmation hostile jusqu’à validation complète. Dessinez la séquence parsing borné, sélection de confiance, validation cryptographique, contrôle de profil puis autorisation. Placez un espion sur le service métier et vérifiez qu’il n’est jamais appelé dans l’état illustré.

La structure ne constitue pas une preuve d’origine et de profil. Un texte de rôle ne prouve pas son autorité. Une date ne valide pas la signature ni le destinataire. La syntaxe JSON ne donne pas de confiance.

Travail pratique : Décodez un jeton de laboratoire, modifiez un claim puis comparez le résultat du décodeur avec celui du validateur.

Critères de correction : Le décodeur peut montrer les deux payloads ; seul le validateur doit établir la confiance. Vérifiez que le jeton modifié n’atteint aucun service métier.

Apple Pay : un token à traiter, pas un résultat de paiement

Apple Pay fournit un objet de paiement contenant un token chiffré après l’authentification du client. Ce token transporte des données nécessaires au traitement, mais le recevoir dans le navigateur ne constitue pas une confirmation de capture ou d’acceptation par la chaîne bancaire.

Dans le cas posé, le PSP sait traiter ce token. Transmettez-le selon son intégration documentée, puis gérez résultat d’autorisation, éventuelle capture et notifications. Vérifiez l’association avec la commande, le montant et la référence d’opération, sans inventer un décodage JWT générique : les tokens ne sont pas interchangeables du seul fait de leur nom.

Utilisez l’environnement de test du fournisseur et distinguez token reçu, traitement en cours, refus et résultat confirmé. Une interface qui affiche payé dès le callback navigateur peut diverger du backend. Conservez un état durable et un mécanisme de rapprochement pour les réponses perdues et événements asynchrones, sans journaliser les données sensibles du token.

Points de vigilance : L’authentification de l’utilisateur et l’approbation financière par l’émetteur sont distinctes. Le PSP peut effectuer le traitement cryptographique ; ce n’est pas une obligation du navigateur. Le token transporte les données nécessaires au traitement ; il ne remplace pas la réponse de la chaîne de paiement. Le cryptogramme de paiement n’est pas un jeton réutilisable pour des transactions distinctes.

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.

Comprendre le mécanisme

JWE définit une représentation chiffrée avec des paramètres de gestion de clé et de chiffrement du contenu. Une forme compacte possède cinq segments, dont certains peuvent être vides selon l’algorithme. Cette structure ne constitue pas une preuve de validité. Un destinataire capable de déchiffrer doit encore déterminer l’origine attendue et les règles du profil ; le chiffrement avec une clé publique de destinataire ne prouve pas qui a envoyé le contenu.

Raisonner et vérifier

Lorsqu’un profil compose signature et chiffrement, vérifiez toutes les couches requises avec une bibliothèque adaptée. Ne retournez pas de diagnostics publics détaillant les étapes cryptographiques. Évaluez aussi les métadonnées et longueurs visibles : chiffrer le contenu ne cache pas toute information de trafic. N’activez pas une compression sensible sans analyse des fuites possibles et des limites de décompression.

Cinq segments

La forme compacte JWE comporte cinq segments. La structure doit encore être validée cryptographiquement. La forme compacte JWE sépare notamment en-tête protégé, clé chiffrée, vecteur, contenu chiffré et tag. Cette structure permet un parsing, mais cinq morceaux arbitraires ne constituent pas une JWE valide.

Expéditeur

Le chiffrement vers une clé publique ne prouve pas l’expéditeur. Le caractère public permet à d’autres de chiffrer vers le destinataire. Une personne qui connaît la clé publique d’un destinataire peut généralement chiffrer pour lui. Le succès du déchiffrement ne désigne donc pas à lui seul un expéditeur autorisé.

Signature interne

Un profil peut exiger une signature interne. Toutes les couches requises doivent être vérifiées. Si le profil impose une composition signée puis chiffrée, vérifiez aussi la signature interne et ses claims. Le déchiffrement réussi n’autorise pas à sauter une opération explicitement exigée.

Deux familles d’algorithmes

Les algorithmes de gestion de clé et de contenu ont des rôles distincts. La construction possède plusieurs paramètres de protection. alg décrit la gestion de clé et enc la protection du contenu dans le profil JOSE. Imposez les combinaisons admises et les capacités de clé correspondantes, au lieu d’accepter toute valeur reconnue.

Erreurs maîtrisées

Les erreurs publiques doivent rester contrôlées. Des diagnostics détaillés peuvent fournir des informations sensibles. Les détails cryptographiques peuvent aider un attaquant ou révéler des informations internes. Retournez un refus public contrôlé et gardez des diagnostics privés minimisés, sans plaintext ni clé dans les logs.

Clé destinataire

Le destinataire doit disposer de la clé prévue. Décodage et déchiffrement sont différents. La clé de déchiffrement doit correspondre au destinataire et à l’usage configurés. Une résolution par kid reste une sélection contrôlée ; elle ne doit pas autoriser des lectures de fichiers arbitraires.

Longueur observable

La longueur peut rester observable. Le contenu secret ne supprime pas toutes les informations visibles. Le chiffrement peut laisser visibles taille, moment et fréquence des échanges. Déterminez si ces métadonnées sont sensibles dans votre modèle avant d’annoncer une confidentialité qui dépasserait le contenu protégé.

Compression

La compression sensible demande une analyse. La taille peut devenir un canal d’information. Compresser un secret avec des données contrôlées peut révéler des corrélations de longueur selon le contexte. Évitez d’activer une compression sensible sans analyse de l’attaquant, des observations et des répétitions possibles.

Parsing borné

Un parseur doit borner les entrées. Le traitement doit protéger ses ressources. Fixez taille totale et limites de décompression lorsqu’elle existe. Une entrée finalement invalide ne doit pas pouvoir consommer sans limite les ressources du service avant la décision de refus.

Après déchiffrement

L’autorisation reste nécessaire après déchiffrement. La protection cryptographique n’épuise pas la décision d’accès. Un contenu déchiffré peut demander une opération interdite au compte. Appliquez validation de profil et autorisation métier ; la confidentialité du transport d’une affirmation ne lui donne pas un droit universel.

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

{
  "profile": "signed-then-encrypted",
  "decryption": "ok",
  "innerSignature": "not-checked"
}

Le profil annoncé exige une signature interne, tandis que l’état montre seulement un déchiffrement réussi. La décision correcte reste le refus tant que la signature requise n’est pas validée. Ajoutez des fixtures pour déchiffrement invalide, signature interne invalide et composition entièrement conforme.

Les contrôles de claims restent nécessaires. La longueur n’est pas la propriété manquante. Toutes les opérations exigées par le profil doivent réussir. La confidentialité ne donne pas ces permissions.

Travail pratique : Testez le profil avec JWS seule, JWE sans signature interne et objet imbriqué complet.

Critères de correction : Refusez les formats incomplets avant le métier. Vérifiez que l’erreur publique ne distingue pas des détails internes sensibles, tout en conservant un diagnostic privé minimal.

Comprendre le mécanisme

Un profil de jeton d’accès précise les claims requis, leurs types et leur sens pour une API. Issuer indique l’autorité attendue, audience les destinataires, subject une identité dans le contexte de cet émetteur. Des scopes décrivent un vocabulaire d’accès du protocole ; leur présence ne remplace pas la propriété d’une ressource. Une API ne doit pas réutiliser un validateur générique sans préciser ses attentes.

Raisonner et vérifier

Construisez une matrice : nom du claim, présence, type, valeurs admissibles, source de confiance et décision associée. Les dates numériques se comparent avec une horloge maîtrisée et une tolérance bornée, documentée plutôt qu’illimitée. Distinguez expiration du token et fin d’une permission métier. Un compte désactivé ou un objet transféré peut rendre une action interdite pendant la durée cryptographique du token.

Émetteur exact

iss doit correspondre à l’émetteur attendu. Le contrat de confiance fixe les autorités acceptées. Comparez iss à un fournisseur configuré selon les règles du profil. Ne téléchargez pas sa configuration depuis n’importe quelle valeur reçue ; cette valeur est initialement une entrée hostile.

Audience attendue

aud doit inclure le consommateur prévu selon le profil. La destination du token doit être vérifiée. Vérifiez que aud désigne votre API, sous la forme prescrite. Un token d’une autre API peut avoir une signature correcte et un sujet connu sans être acceptable pour ce consommateur.

Expiration

exp numérique représente une limite temporelle selon le profil. Type et comparaison temporelle sont nécessaires. Contrôlez le type numérique et la borne temporelle définie. Un exp absent, texte ou expiré doit suivre la règle du profil, sans conversion permissive inventée par un helper local.

Horloge

Une horloge injectée rend les limites testables. Le temps peut être un paramètre contrôlé. Injectez une horloge dans les tests pour essayer juste avant, à la borne et après exp ou nbf. Vous obtenez une preuve reproductible sans sommeil ni dépendance à la vitesse de la machine.

Tolérance

La tolérance temporelle doit être bornée. Une marge illimitée annule la limite recherchée. Une petite marge peut traiter un écart d’horloge prévu. Fixez-la explicitement et testez sa borne ; une tolérance très large transforme un mécanisme d’expiration court en fenêtre d’usage beaucoup plus longue.

Scope et objet

Un scope ne remplace pas les droits sur un objet. La politique métier doit préciser le périmètre. Un scope reservations:read permet une catégorie d’opération dans le contrat. Il ne prouve pas que chaque réservation appartient au sujet ; ajoutez un contrôle de tenant et de relation à l’objet.

Sujet contextualisé

Le sujet s’interprète dans son contexte d’émetteur. Le namespace d’identité dépend du contrat. Deux émetteurs peuvent utiliser la même valeur sub pour des personnes différentes. Identifiez un compte avec le contexte de son fournisseur et les règles de liaison maîtrisées par l’application.

Désactivation

Un compte désactivé peut exiger un contrôle supplémentaire. La validité temporelle du token et l’état métier diffèrent. Si un compte suspendu doit être refusé immédiatement, un token autonome peut demander un état supplémentaire. Définissez le délai attendu et vérifiez chaque consommateur, caches compris.

Contrat complet

Les claims requis doivent être explicités. Les absences et types doivent avoir des règles définies. Documentez signature, algorithmes, clé, iss, aud, types et claims temporels requis. Une liste de champs lue par le code n’est pas encore une politique d’acceptation cohérente.

Refus signé

Un test négatif doit utiliser aussi des signatures valides. Une signature correcte isole le contrôle de destination. Pour tester l’audience, utilisez un token correctement signé avec la mauvaise audience. Sinon, un rejet cryptographique préalable pourrait masquer le fait que le contrôle d’audience n’est jamais appliqué.

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

{
  "expectedAudience": "reservation-api",
  "verifiedClaims": {
    "iss": "https://identity.example.test",
    "aud": "stock-api",
    "exp": 4102444800
  }
}

Le token illustré a pour audience stock-api alors que le consommateur attend reservation-api. Cette différence suffit à refuser selon le profil, malgré la signature et la date supposées valides. Contrôlez l’absence d’appel métier puis ajoutez un token identique avec l’audience admise pour vérifier le chemin nominal.

La validation du profil ne se réduit pas à la signature. Le consommateur n’est pas la destination annoncée. La date ne corrige pas le destinataire. Modifier les claims ne rend pas l’émission légitime.

Travail pratique : Produisez des tokens correctement signés mais avec mauvais issuer, mauvaise audience, expiration passée et date de mauvais type.

Critères de correction : Injectez une horloge fixe. Les quatre cas sont refusés et le token nominal réussit. Testez ensuite l’accès à une réservation tierce pour démontrer l’autorisation distincte.

JWT : de la preuve cryptographique au droit sur l’objet

Un émetteur reconnu ne rend pas acceptable tout token qui mentionne son nom. Le validateur doit choisir une clé admise, imposer l’algorithme autorisé et vérifier la signature avec une bibliothèque configurée pour ce profil.

Il contrôle ensuite émetteur, audience, claims nécessaires et validité temporelle avec leurs types et la tolérance prévue. Une signature correcte destinée à une autre API reste un motif de refus. Les claims ne doivent pas produire une identité de confiance avant la réussite de ces étapes.

Enfin, une identité ou un scope ne donne pas automatiquement accès à tous les objets. Chargez la ressource dans la portée autorisée et vérifiez l’opération métier. Pour chaque contrôle, utilisez une fixture qui passe les étapes précédentes : token signé avec mauvaise audience, token expiré et token valide d’un autre propriétaire. Vérifiez refus avant effet et un cas nominal, sans conserver les tokens réels dans les logs.

Points de vigilance : L’authenticité, le destinataire, la période de validité et l’autorisation répondent à des questions distinctes. Décoder ne prouve pas l’authenticité du payload. Le token non fiable ne doit pas pouvoir imposer une source arbitraire de clés de confiance. La présence d’un rôle ne prouve pas le droit d’agir sur une ressource donnée.

SCA et liaison dynamique : le montant authentifié doit correspondre

Le cas est explicitement une opération UE soumise à la SCA avec liaison dynamique au montant et au bénéficiaire. Dans ce périmètre, le code est lié aux données de l’opération présentée au payeur ; il ne représente pas une autorisation générale de payer un montant choisi ultérieurement.

Si le montant change, l’ancien code ne doit pas être accepté comme preuve pour la nouvelle opération. Reprenez le parcours applicable avec le PSP et présentez les données cohérentes au payeur. Le backend doit relier état d’authentification et version de l’intention pour éviter une modification tardive après validation.

Testez un montant inchangé et un montant modifié, puis vérifiez l’absence de traitement fondé sur l’ancienne preuve. La réussite d’une signature JWT ou d’une session ne remplace pas cette liaison. Les exemptions et autres flux ont des conditions propres ; elles ne sont pas une hypothèse implicite permettant d’éluder le cas posé.

Points de vigilance : Le code est lié aux données de transaction dans le scénario décrit. Aucune tolérance générale de ce type n’est donnée par cette règle de liaison dynamique. Un changement du montant invalide le code associé à l’opération initiale ; traiter le nouveau parcours selon les règles applicables. Une exemption ne se décide pas par un flag arbitraire ; son éligibilité dépend du cadre applicable.

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.

Comprendre le mécanisme

Un JWK représente une clé avec des paramètres et métadonnées. Un jeu public de clés ne doit contenir que les éléments publics attendus. Le champ kid peut aider à sélectionner une clé ; il n’authentifie ni le token ni la destination réseau. Des clés de même identifiant dans des contextes différents ne doivent pas se confondre : issuer, usage et algorithme font partie de la résolution.

Raisonner et vérifier

Ne transformez jamais kid en chemin de fichier libre ni jku en URL de téléchargement arbitraire. Le jeu de clés est lié à un fournisseur admis. Borner réponse, délai, cache et renouvellement protège aussi contre l’abus de tokens à identifiants inconnus. Si la clé ne peut pas être résolue selon le contrat, refusez l’accès ; un ancien résultat positif ne doit pas faire accepter n’importe quelle signature.

Référence hostile

kid est une référence non fiable à résoudre. La référence ne prouve ni clé ni émetteur. kid vient du token reçu et doit être traité comme une donnée non fiable. Résolvez-le dans une table ou un jeu de clés maîtrisé plutôt que le convertir directement en chemin, requête ou URL.

Contexte de sélection

Une résolution peut dépendre de issuer et usage. Le contexte de confiance compte. Un même identifiant peut exister chez deux fournisseurs. La résolution doit tenir compte de l’émetteur admis et de l’usage attendu afin d’éviter qu’une clé valide dans un autre contexte soit choisie.

Jeu public

Le jeu public ne doit pas exposer les paramètres privés. La vérification asymétrique utilise les données publiques. Une JWKS publique destinée à vérifier des signatures ne doit contenir que les paramètres publics prévus. Vérifiez les exports afin qu’une sérialisation d’objet de clé n’ajoute pas ses paramètres privés.

URL contrôlée

Une URL de clés doit être maîtrisée. Cela peut détourner la confiance et les sorties réseau. Une valeur jku arbitraire peut diriger le serveur vers une destination hostile ou interne. Partez d’une configuration de fournisseur maîtrisée et appliquez aussi la politique de sorties réseau.

Aucun chemin libre

kid ne doit pas devenir un chemin libre. Le client ne doit pas sélectionner arbitrairement des fichiers. Concaténer ../other-secret à un répertoire de clés permet une traversée de chemin. Une table de références exactes évite de donner au porteur une capacité générale de lecture du système de fichiers.

Clé inconnue

Une clé inconnue doit suivre une actualisation bornée. Une entrée hostile peut sinon amplifier le travail. Une rotation peut justifier une actualisation JWKS, mais celle-ci doit être bornée et mutualisée. Des kid aléatoires en rafale ne doivent pas provoquer un appel externe coûteux pour chaque requête.

Ambiguïté

Un jeu ambigu demande une politique explicite. La résolution doit rester déterministe et sûre. Deux clés portant le même identifiant ou des usages incompatibles demandent un refus ou une politique explicite. Ne choisissez pas simplement le premier élément si cette règle n’établit pas une correspondance sûre.

Paramètres compatibles

Les paramètres de clé doivent être compatibles. Le type de clé fait partie de la validation. Contrôlez type de clé, usage et algorithme selon le profil. La présence d’un kid connu ne donne pas à une clé la capacité de vérifier n’importe quelle famille cryptographique.

Sélection puis preuve

Sélectionner une clé ne vérifie pas encore la signature. La preuve doit être vérifiée avec la clé sélectionnée. Trouver la clé ne valide pas la signature. Gardez ces étapes distinctes et vérifiez qu’un token altéré avec un kid existant est encore refusé avant tout traitement métier.

Cycle de cache

Le cache doit avoir un cycle documenté. Rotation et incident peuvent modifier les attentes. Documentez durée, rafraîchissement, panne et invalidation en incident. Un cache améliore la disponibilité mais peut retarder le retrait d’une clé compromise si aucune politique spécifique n’est prévue.

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

<?php
declare(strict_types=1);
$kid = '../other-secret'; // entrée simulée non fiable
$path = '/srv/lab/keys/'.$kid.'.pem';
echo $path;

La concaténation de kid dans un chemin transforme une référence hostile en accès au système de fichiers. Ne cherchez pas seulement à retirer les deux points : remplacez cette résolution libre par une sélection dans le jeu de clés admis pour le fournisseur et l’usage du token.

Une extension ne valide pas la provenance ni le droit de lecture. Un préfixe seul ne confine pas les chemins. Aucune vérification cryptographique n’a lieu. La référence doit être résolue dans un jeu de clés maîtrisé.

Travail pratique : Testez kid connu, inconnu, doublon ambigu et chaîne ressemblant à un chemin dans un validateur isolé.

Critères de correction : Refusez les cas non résolus sans lecture arbitraire. Vérifiez le nombre d’accès réseau et l’absence de paramètres privés dans le jeu public.

Comprendre le mécanisme

La découverte OpenID Connect permet d’obtenir des métadonnées d’un fournisseur attendu, dont une localisation de clés. Elle ne rend pas fiable un issuer choisi librement par un token. La relation entre configuration locale, issuer exact et métadonnées doit être vérifiée avec TLS et des limites réseau. Les caches de métadonnées possèdent un cycle distinct de celui des jetons.

Raisonner et vérifier

Une rotation normale peut publier une nouvelle clé avant son utilisation et conserver temporairement les anciennes clés nécessaires aux tokens encore acceptés. Une compromission demande une autre stratégie, liée au délai de révocation admis. Prévoyez cache expiré, fournisseur indisponible et identifiant inconnu avec actualisation bornée. La disponibilité ne doit pas entraîner une acceptation sans vérification.

Fournisseur configuré

La découverte part d’un fournisseur attendu. La confiance précède les métadonnées téléchargées. La découverte part d’une identité attendue et admise. Un token ne doit pas pouvoir faire accepter un nouvel émetteur simplement en annonçant son URL et des métadonnées cohérentes avec lui-même.

Canal vérifié

Le TLS de récupération doit être vérifié. Les métadonnées doivent venir du pair attendu. Le téléchargement des métadonnées et des clés doit vérifier TLS et la destination. Une récupération réussie avec validation désactivée permettrait à un intermédiaire de remplacer la base de confiance.

Publication préalable

Une nouvelle clé peut être publiée avant son usage. Les consommateurs doivent pouvoir obtenir la clé utile. Publiez K2 avant de commencer à signer avec elle. Les consommateurs peuvent ainsi actualiser leurs caches ; testez la chronologie au lieu de supposer que toute distribution est instantanée.

Chevauchement normal

Les anciennes clés peuvent rester pendant une transition définie. Le calendrier dépend des tokens encore acceptés. Gardez K1 le temps nécessaire aux tokens encore valides selon la politique. Reliez cette durée à leur expiration et aux tolérances, puis retirez-la lorsque la transition prévue est terminée.

Incident distinct

Une compromission peut exiger une autre chronologie. Le risque et le retrait demandé diffèrent. Une compromission de K1 peut imposer un retrait plus rapide que la rotation normale. Prévoyez invalidation de cache et communication opérationnelle, en acceptant les conséquences de refus nécessaires selon le risque.

Actualisations bornées

Les actualisations doivent être bornées. La récupération est aussi une surface de consommation. Fixez délais réseau, taille maximale et fréquence de rafraîchissement. Un fournisseur lent ou une rafale de références inconnues ne doit pas monopoliser tous les workers de l’API.

Disponibilité et confiance

Le cache peut améliorer la disponibilité sans supprimer la validation. L’absence de clé utilisable ne prouve pas l’authenticité. Une clé encore admise en cache peut permettre de continuer selon la politique. Sans aucune clé valide disponible, refusez ; une panne du fournisseur ne justifie pas l’acceptation sans preuve.

Métadonnées cohérentes

Les métadonnées doivent correspondre au fournisseur configuré. Les relations d’issuer et de destination doivent rester contrôlées. Vérifiez les champs qui lient configuration et fournisseur attendu. Une adresse JWKS présente dans un document quelconque ne devient pas automatiquement une source autorisée pour votre API.

Chronologie testée

Une chronologie de test doit couvrir les deux clés. Le chevauchement et le retrait doivent être observés. Essayez tokens K1 et K2 avant publication, pendant chevauchement et après retrait. Contrôlez également une instance qui conserve un cache ancien pour mesurer la propagation réelle.

Consommateurs observés

Un incident doit mesurer les consommateurs réels. Les caches et déploiements peuvent conserver des états différents. L’émission avec K2 ne démontre pas le retrait de K1 partout. Vérifiez API, workers et services partenaires inclus dans le périmètre et consignez le délai de refus observé.

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

t0: JWKS publie K1 + K2
 t1: l’émetteur commence à signer avec K2
 t2: K1 est retirée selon la politique de durée

L’ordre t0 puis t1 prépare les vérificateurs avant l’émission de tokens K2. Le retrait de K1 à t2 suit la durée définie pour la transition normale. Rejouez le scénario avec un cache lent puis distinguez la procédure exceptionnelle nécessaire si K1 est compromise.

La rotation ne retire pas ces exigences. Ce calendrier normal ne prouve pas l’absence d’incident. La distribution prépare la transition des vérificateurs. Seuls les paramètres publics doivent être distribués ainsi.

Travail pratique : Simulez deux versions du jeu de clés et une panne de récupération pendant la transition.

Critères de correction : Vérifiez l’acceptation attendue de K1/K2 sur une chronologie fixée, le nombre borné de récupérations et le refus en l’absence de clé utilisable.

Comprendre le mécanisme

OpenID Connect ajoute une couche d’identité à OAuth. L’ID token exprime des informations destinées au client selon le flux OIDC, avec des règles de validation propres. Un access token sert à présenter une autorisation au serveur de ressources selon son profil ; il peut être opaque ou structuré. La présence d’un utilisateur dans les deux ne les rend pas interchangeables.

Raisonner et vérifier

Attribuez à chaque composant le jeton qu’il doit consommer. Le client valide son contexte d’authentification, notamment nonce lorsqu’il est requis par le flux, tandis que l’API valide son audience et ses règles d’accès. Un token ne remplace pas les contrôles du protocole de redirection. Documentez les flux et bibliothèques choisis plutôt que reconstituer OAuth à partir de trois segments.

Destinataire OIDC

Un ID token vise le client OIDC selon son profil. Les consommateurs et profils doivent être distingués. Un ID token informe le client OIDC d’un résultat d’authentification selon son flux. Une API de ressources ne doit pas l’accepter comme jeton d’accès simplement parce que sa signature est valide.

Token opaque

Un access token peut être opaque. Le protocole ne fixe pas universellement cette représentation. Le rôle access token n’impose pas une représentation JWT. Le serveur de ressources applique le mécanisme prévu, par exemple introspection ou validation locale, sans tenter de décoder arbitrairement toute chaîne.

Audience API

Une API doit vérifier sa propre audience attendue. La destination reste une exigence du profil. Votre API vérifie sa propre audience dans le profil approprié. Un token destiné à web-client ne devient pas acceptable pour reservation-api parce que les deux appartiennent à la même organisation.

Nonce

nonce peut lier le contexte selon le flux OIDC. Les contrôles de contexte et de preuve sont complémentaires. Dans les flux où il est utilisé, nonce relie la réponse au contexte initié par le client. Il complète les autres validations OIDC et ne remplace jamais à lui seul signature ou contrôle d’émetteur.

Flux choisi

Le client doit suivre les règles du flux choisi. La sérialisation ne définit pas tout le protocole. Code, échanges serveur et stockage de contexte ont des exigences précises. Utilisez une bibliothèque de protocole et testez les chemins d’erreur, plutôt que reconstruire un login en lisant seulement les claims.

Redirection

Les règles de redirection restent nécessaires. Le protocole de retour a ses propres contraintes. Les destinations de retour doivent être enregistrées et comparées selon les règles applicables. Une redirection trop libre peut détourner un code ou un token malgré une authentification utilisateur correcte.

Sujet et droit

Le sujet d’un ID token ne prouve pas toute permission d’API. L’identité ne détermine pas seule les droits. Le sujet authentifié peut être reconnu par le client sans posséder de permission sur une facture de l’API. Les droits de ressource doivent être évalués dans leur contexte métier.

Substitution signée

Une substitution de profil doit être testée avec une signature valide. Un cas correctement signé isole le contrôle de profil. Testez un ID token correctement signé là où un access token est exigé. Une signature volontairement invalide ne démontre pas le rejet du mauvais profil puisqu’elle échoue plus tôt.

Bibliothèque adaptée

Une bibliothèque adaptée aide à appliquer le protocole. Il manque les échanges et vérifications du flux. Une bibliothèque JWT générale ne fournit pas nécessairement tout le flux OIDC. Vérifiez gestion d’état, nonce, découverte et erreurs requises par le rôle que votre composant assume.

Claims ressemblants

L’ID token et l’access token peuvent partager des claims sans être interchangeables. La signification dépend du rôle et du destinataire. iss, sub et exp peuvent apparaître dans plusieurs tokens. Leur ressemblance ne rend pas les profils interchangeables ; type, audience et règles du protocole déterminent l’usage admissible.

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

{
  "consumer": "reservation-api",
  "receivedProfile": "ID token",
  "aud": "web-client",
  "signature": "valid"
}

Le token reçu est explicitement un ID token pour web-client et le consommateur est reservation-api. Sa signature valide ne corrige ni le rôle ni l’audience. Écrivez un test de substitution avec une preuve correcte et confirmez le refus avant tout accès aux données de réservation.

La preuve ne remplace pas le contrat de destination. La validation doit refuser la substitution de rôle et d’audience. Les deux usages ne sont pas interchangeables. Les noms désignent des consommateurs différents.

Travail pratique : Préparez un ID token et un access token de laboratoire avec audiences différentes. Envoyez chacun aux deux composants.

Critères de correction : Seules les combinaisons du contrat doivent réussir. Vérifiez que l’API refuse un token d’identité même si sa signature est correcte et son utilisateur connu.

Comprendre le mécanisme

Un bearer token volé peut être rejoué par son détenteur dans le périmètre accepté. Stocker une valeur dans localStorage la rend accessible aux scripts de l’origine ; une XSS peut donc la lire. Un cookie HttpOnly empêche cette lecture directe via les API JavaScript habituelles, mais le navigateur peut encore envoyer le cookie sur des requêtes. Aucun de ces choix ne supprime les risques du navigateur.

Raisonner et vérifier

Comparez exposition au script, envoi automatique, politique SameSite, durée et révocation. Un modèle avec serveur intermédiaire conservant les tokens côté serveur peut réduire leur exposition au navigateur, mais conserve ses propres exigences de session et CSRF. Ne placez pas de bearer token dans une URL susceptible d’être journalisée. Testez le modèle choisi avec un contrôle d’origine et des mutations protégées.

Scripts de l’origine

Les scripts d’origine peuvent lire localStorage. L’API de stockage est accessible au JavaScript autorisé dans l’origine. Un script exécuté sur l’origine peut accéder à localStorage. Une XSS ou un script tiers compromis dans ce contexte peut donc lire un bearer token stocké ainsi et l’exfiltrer.

Portée de HttpOnly

Un cookie HttpOnly limite la lecture directe par script. Le script peut encore agir dans le contexte compromis. HttpOnly bloque la lecture directe du cookie par JavaScript. Le script injecté peut encore agir dans la page et déclencher des demandes authentifiées ; cette protection ne supprime pas toutes les conséquences d’une XSS.

Envoi automatique

Les cookies peuvent être envoyés automatiquement. Le navigateur applique sa politique d’envoi. Les cookies sont joints selon leur portée et les règles du navigateur. Cette commodité crée un besoin de protection CSRF sur les actions sensibles, distinct de la confidentialité du cookie.

Comparer les menaces

Le modèle doit comparer XSS et CSRF. Les capacités de lecture et d’envoi diffèrent. Évaluez lecture et exfiltration de credentials, action depuis la page et envoi automatique depuis un autre site. Le choix de stockage doit répondre à ces scénarios concrets plutôt qu’à une règle universelle.

URL

Un bearer token en URL peut fuiter par des traces. Le chiffrement du canal n’efface pas l’historique et les logs. Un bearer token dans la query peut finir dans historique, logs et références. Préférez le canal prévu par le protocole et configurez aussi la minimisation des traces côté proxy et application.

Backend intermédiaire

Un backend intermédiaire peut conserver les tokens côté serveur. La session navigateur reste à protéger. Un BFF peut conserver les tokens côté serveur et exposer une session au navigateur. Il faut alors protéger session, CSRF et échanges internes ; déplacer un secret ne retire pas tous les risques.

Durée d’usage

La durée limite une fenêtre d’usage selon le contrat. La longueur ne définit pas le cycle de vie. Un token court borne une fenêtre selon la validation d’expiration. Il reste utilisable durant cette fenêtre par un voleur ; la durée ne remplace ni prévention XSS ni politique de retrait.

Chiffrement et porteur

Le chiffrement d’un token ne protège pas sa réutilisation comme bearer. Le détenteur peut parfois présenter la valeur sans la déchiffrer. Si le serveur accepte la chaîne chiffrée comme bearer, un voleur peut la rejouer sans la déchiffrer. La confidentialité des claims et la prévention de réutilisation sont des propriétés distinctes.

Parcours réel

La politique de cookies doit être vérifiée sur le parcours réel. Il faut observer les attributs effectivement émis. Vérifiez attributs et envoi des cookies dans les contextes effectivement utilisés : navigation, iframe, sous-domaines et requêtes cross-origin. Un test isolé sur une seule page peut manquer une frontière importante.

Logout défini

Le logout doit définir ce qu’il retire. Les validateurs ne dépendent pas de cette seule suppression. Effacer une valeur locale retire cette copie, pas toutes les copies distribuées. Définissez ce que le serveur invalide et le délai de refus attendu, puis testez une ancienne valeur conservée hors du navigateur.

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

localStorage.setItem('lab-access-token', 'public-fixture-only');
const value = localStorage.getItem('lab-access-token');

Le script écrit puis relit le token de laboratoire dans localStorage : les scripts de cette origine y ont donc accès. N’utilisez aucune valeur réelle pour cette démonstration. Comparez ensuite avec les propriétés d’un cookie HttpOnly, en gardant les scénarios d’action XSS et de CSRF dans l’analyse.

localStorage est exposé aux scripts de l’origine. HttpOnly est un attribut de cookie, pas de localStorage. Le nom de clé n’établit pas un contrôle d’accès. Le stockage ne dépend pas de cette autorité.

Travail pratique : Comparez une session cookie et un token lisible par JavaScript sur un même portail local. Listez trois menaces de chaque modèle.

Critères de correction : Vérifiez les attributs réels du cookie, les accès du script et les chemins de mutation. Documentez les contrôles XSS et CSRF sans annoncer qu’un attribut unique les élimine.

Comprendre le mécanisme

Un jeton autonome vérifié localement peut rester accepté jusqu’à expiration si le validateur ne consulte aucun état de révocation. Une opération de révocation chez un fournisseur ne se propage donc pas magiquement à toutes les API. Le système doit choisir entre vérifications d’état, durées courtes, listes ciblées ou autre mécanisme documenté, avec ses coûts de disponibilité et de cohérence.

Raisonner et vérifier

Distinguez logout du navigateur, retrait d’un refresh token et invalidation d’un access token déjà émis. Le délai maximal d’acceptation après désactivation doit être mesuré, pas déduit du mot stateless. Une compromission de clé peut imposer une action plus large qu’une seule session. Testez chronologie, cache et instances avec une horloge contrôlée et des clés de laboratoire.

Acceptation autonome

Un token autonome peut rester accepté jusqu’à exp. Les validateurs doivent recevoir ou consulter un état pertinent. Un validateur qui contrôle seulement signature et exp peut accepter une ancienne copie jusqu’à l’échéance. La suppression dans un navigateur ne change pas les octets ni les règles de ce validateur.

Deux capacités

Retrait de refresh token et d’access token sont distincts. Le mécanisme des serveurs de ressources compte. Retirer le refresh token empêche un renouvellement selon la politique serveur. Les access tokens déjà émis suivent leur propre validation et peuvent rester admis tant qu’aucun mécanisme ne les retire.

Délai mesuré

Le délai de retrait doit être mesuré. Il ne précise pas de propagation de révocation. Définissez un objectif de retrait puis observez les refus sur tous les consommateurs. Une intention dans la documentation ne démontre pas le comportement d’un cache ou d’un worker encore actif.

Liste de retrait

Une liste de retrait ajoute un état à consulter. La cohérence entre consommateurs demande une conception. Une denylist ajoute une consultation d’état et un besoin de disponibilité. Définissez index, expiration des entrées et politique de panne ; cette solution modifie le caractère purement autonome de la validation.

Durées courtes

Des durées courtes peuvent réduire une fenêtre. Le risque accepté et les exigences peuvent imposer davantage. Réduire la durée d’un access token peut limiter l’exposition après vol. Évaluez aussi fréquence de renouvellement, charge et expérience utilisateur ; une durée courte ne rend pas une révocation instantanée.

Clé compromise

Une clé compromise peut concerner plusieurs sessions. La capacité d’émission peut être plus large. Le retrait d’une clé peut toucher de nombreux tokens et utilisateurs. La procédure doit distinguer session isolée et incident global, avec moyen de distribution rapide et résultat de refus vérifiable.

Caches

Les caches doivent entrer dans la mesure de propagation. Il peut conserver des décisions ou états anciens. Incluez caches de clés, état de compte et listes de retrait dans la chronologie. Un cache trop long peut dépasser le délai annoncé même si la base centrale a déjà enregistré la révocation.

Horloge de test

Une horloge de test aide à vérifier le retrait. Le laboratoire peut contrôler le temps sans affecter le service réel. Avec une horloge contrôlée, vérifiez avant et après exp et autour du retrait. Évitez les sleeps ; ils rendent la suite lente et peuvent cacher une interprétation imprécise des bornes.

État du compte

Une désactivation métier peut demander un contrôle d’état. Les états métier et temporels du token sont distincts. Une suspension de compte peut exiger une consultation ou une version de sécurité contrôlée. Écrivez explicitement si le retrait est immédiat ou différé, puis vérifiez le mécanisme choisi.

Diagnostic expurgé

Les traces d’incident doivent rester expurgées. Des identifiants et catégories contrôlés peuvent suffire. Conservez catégorie d’incident, identifiant non sensible et version du mécanisme. Le token brut dans les logs créerait une nouvelle copie exploitable au moment même où vous essayez de retirer l’accès.

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

token:
  exp: 2000
validator_clock: 1500
logout_in_browser: true
validator_checks_revocation: false
signature_and_profile: valid

L’horloge du validateur est antérieure à exp et aucun état de retrait n’est consulté. Le logout local ne change donc pas la décision décrite. Ajoutez une politique serveur si un refus avant exp est exigé, puis mesurez ce refus avec une copie conservée du token.

1500 est inférieur à 2000 dans cet exercice temporel. Le stockage navigateur ne change pas une signature émise. Aucun mécanisme de propagation n’est défini. Le validateur décrit ne consulte aucun état de retrait.

Travail pratique : Désactivez un compte de test pendant qu’un token est encore dans sa période nominale.

Critères de correction : Mesurez les refus sur chaque instance, puis comparez avec le délai annoncé. Documentez séparément ce qui est retiré au logout et ce qui demeure utilisable ailleurs.

Comprendre le mécanisme

Un refresh token permet d’obtenir de nouveaux tokens selon un contrat avec le serveur d’autorisation. Sa valeur n’a pas besoin d’être un JWT pour être sensible. La rotation et la détection de réutilisation peuvent limiter certains scénarios de vol ; leur efficacité dépend du suivi serveur et de la gestion des accès concurrents. Une course légitime et une réutilisation hostile ne se distinguent pas par la longueur du texte.

Raisonner et vérifier

Les recommandations OAuth actuelles demandent une analyse du type de client et du flux. PKCE protège le code d’autorisation dans son contexte, sans remplacer TLS ni toute validation de redirection. Ne mélangez pas ces garanties avec celles d’une signature JWT. Planifiez perte de réponse lors d’une rotation, plusieurs onglets et incident de refresh token avec une politique explicite et testée.

Capacité durable

Un refresh token donne une capacité de renouvellement. Sa possession peut permettre l’obtention de nouveaux tokens. Le refresh token peut permettre d’obtenir de nouveaux access tokens. Protégez-le comme une capacité de longue durée, avec politique de stockage, durée et retrait distincte de celle d’un token d’accès.

Format indépendant

Le format refresh peut être opaque. Le rôle ne fixe pas cette représentation. Un refresh token peut être opaque et résolu dans un état serveur. Son rôle ne dépend pas du nombre de segments ; ne lui appliquez pas automatiquement un validateur destiné aux JWT d’accès.

Rotation suivie

La rotation demande un suivi serveur. Le cycle doit être appliqué par le serveur. Après échange de R1 contre R2, le serveur conserve assez d’état pour reconnaître une réutilisation de R1. Émettre simplement une nouvelle chaîne sans suivi ne démontre pas cette détection.

Famille de tokens

Une réutilisation peut déclencher une politique de famille. La rotation et la détection ont précisément un autre but. Une réutilisation peut déclencher le retrait de la famille selon la politique retenue. Définissez précisément quels descendants cessent de fonctionner et comment l’utilisateur légitime rétablit sa session.

Réponse perdue

Une perte de réponse peut compliquer le renouvellement. Il faut distinguer risque et concurrence légitime selon le contrat. Le serveur peut consommer R1 puis perdre la réponse contenant R2. Une reprise du client ressemble alors à une réutilisation ; la politique doit traiter ce scénario sans inventer une acceptation illimitée de l’ancien secret.

Onglets concurrents

Plusieurs onglets peuvent créer des courses. Des clients concurrents peuvent agir sur la même famille. Deux onglets peuvent renouveler simultanément la même session. Coordonnez les demandes ou définissez une règle serveur explicite, puis testez les courses plutôt que supposer un navigateur avec un seul appelant.

Rôle de PKCE

PKCE protège un aspect du flux de code. Les mécanismes ont des garanties complémentaires. PKCE lie un échange de code à une preuve du client initiateur selon le flux. Il ne remplace pas TLS, validation des redirections, contrôle d’émetteur ou autres protections requises par le protocole.

Types de clients

Les types de clients influencent les exigences du protocole. Un client public et un client confidentiel diffèrent. Un client public ne peut pas protéger un secret distribué comme un backend confidentiel. Appliquez les exigences correspondant à ce rôle réel, sans traiter un secret embarqué dans JavaScript comme confidentiel.

Logs

Les valeurs refresh ne doivent pas être copiées dans les logs. Des références et événements minimisés peuvent servir à la détection. Enregistrez événements de rotation et de réutilisation avec références non sensibles. La copie des valeurs refresh dans une trace ou un ticket distribuerait précisément la capacité de renouvellement à protéger.

Incident utilisateur

Le scénario d’incident doit prévoir l’utilisateur légitime. Le traitement peut interrompre une session et demander une reprise. Prévoyez reconnexion, information et suivi après retrait de famille. La détection doit produire une réaction vérifiable tout en permettant de distinguer les courses normales des signes d’un vol selon la politique.

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

refresh_policy: rotate_and_detect_reuse
history:
  - R1 accepted, R2 issued
  - R1 presented again

L’historique montre R1 accepté puis représenté alors que la politique exige rotation et détection de réutilisation. Il faut appliquer la réaction prévue à la famille, pas seulement émettre encore un token. Ajoutez au test une réponse perdue et deux onglets pour vérifier la politique dans les cas ambigus.

La politique annoncée ne donne pas ce cycle illimité. Perte de réponse ou concurrence doivent aussi entrer dans l’analyse. Le serveur doit appliquer la réaction prévue pour la famille. Le scénario porte sur le renouvellement applicatif.

Travail pratique : Simulez une rotation réussie, la perte de sa réponse puis la réutilisation de l’ancien token depuis deux clients locaux.

Critères de correction : Vérifiez les événements et le traitement de la famille de tokens selon le contrat retenu. Ne journalisez aucune valeur brute. Documentez les effets sur un utilisateur légitime lors d’un incident.

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.