Elysia Tools
Navigation mobile
Workflow Playbook
Créez un JWT de test contrôlé ou inspectez un échantillon autorisé, puis examinez les claims, l’algorithme, l’expiration, les champs sensibles et les éléments de signature sans confondre décodage et vérification.
Dossiers
Ce parcours s’adresse aux développeurs, équipes d’identité et reviewers qui doivent tirer une conclusion vérifiable d’un échantillon JWT. Commencez par un token synthétique ou autorisé, notez la politique du service et séparez construction du fixture, inspection structurelle et revue de sécurité. Un token reste sensible même dans un diagnostic.
Utilisez jwt-generator pour obtenir des claims et des dates prévisibles dans un cas reproductible. Utilisez jwt-decoder pour observer le header et le payload et vérifier la présence de iss, aud, iat, nbf et exp. Ce n’est pas une vérification : le décodage révèle des données encodées, mais ne prouve pas l’identité du signataire.
Passez ensuite par jwt-decoder-security-auditor. Il peut signaler l’algorithme, l’état de signature, les incohérences temporelles et les noms de claims sensibles ; avec une clé autorisée, il peut aussi vérifier les chemins HS256 ou RS256 qu’il prend en charge. Une clé absente signifie non vérifié.
Comparez les résultats aux algorithmes autorisés, à l’issuer et à l’audience attendus, à la tolérance d’horloge et à la gestion de l’expiration. Après correction, relancez la revue uniquement sur un fixture masqué et consignez accepter, corriger ou bloquer. Pour le périmètre plus large des identifiants, consultez auth-token-security ; pour les clés et signatures hors JWT, consultez key-generation-signature-verification.
Guide de workflow
Générez un JWT non productif avec l’issuer, l’audience, le sujet, l’expiration et les claims personnalisées utiles au cas. Gardez le secret réservé au test et notez l’algorithme visé avant de continuer.
Décodez l’échantillon autorisé ou le fixture généré et examinez séparément le header et le payload. Vérifiez les claims temporelles présentes, en rappelant que cette étape ne prouve pas la validité de la signature.
Soumettez le même échantillon contrôlé à l’auditeur pour relever les risques d’algorithme, l’état de signature, les dates expirées ou futures, l’absence d’issuer ou d’audience et les noms de claims sensibles. N’ajoutez une clé que si son usage est autorisé.
Traitez uniquement les constats liés à l’objectif du test, relancez l’auditeur avec un fixture masqué et indiquez les observations acceptées, celles qui exigent une évolution de politique et celles qui restent non vérifiées faute de clé.
Choisissez jwt-generator pour obtenir des claims, des dates et un algorithme prévisibles dans un test. Choisissez jwt-decoder pour un échantillon autorisé lorsque recréer un token risquerait de masquer le comportement à analyser.
jwt-decoder affiche le header et le payload, mais ne valide pas la signature. Utilisez jwt-decoder-security-auditor pour les constats de sécurité et ne fournissez un secret HS256 ou une clé publique RS256 que si la vérification est autorisée.
Conservez le type de constat et le nom de la claim si cela aide la revue, mais masquez les valeurs qui identifient un utilisateur, un tenant, une session, une adresse e-mail ou un secret. Un payload décodé est encodé en base64url, il n’est pas chiffré.