01. JWT : représentation et confiance

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.