La première fois que j'ai dû déboguer un flux d'authentification cassé sur une API Laravel, j'ai perdu un après-midi parce que je ne pouvais pas produire un jeton en qui j'avais confiance Le middleware revenait sans cesse le 401, et je ne pouvais pas dire si le bug était dans mon code de vérification ou dans le jeton que je le nourrissais J'avais besoin d'un JWT connu-bon avec un spécifique sub1, une expiration spécifique, et un secret que je contrôlais, pour pouvoir isoler un côté du problème La copie d'un jeton aléatoire à partir d'une réponse Stack Overflow a fait le contraire de l'aide, car il a été signé avec un secret que je n'avais pas.
C'est l'écart qu'un générateur JWT comble Ce n'est pas un service de signature de production C'est un outil de banc pour le moment où vous construisez ou testez quelque chose qui consomme des JSON Web Tokens et vous en avez besoin d'un valide à la demande, avec les revendications exactes et le secret exact que vous choisissez Ce guide couvre le fonctionnement de l'outil, comment un JWT est assemblé et signé, et les cas pratiques où générer un jeton à la main vous permet d'économiser du temps réel.
tl;dr : Un générateur JWT transforme une charge utile JSON plus un secret en jeton signé Collez vos réclamations, choisissez HS256, HS384 ou HS512, entrez le secret et copiez le jeton. Le Générateur JWT signez avec l'API Web Crypto du navigateur, afin que la charge utile et le secret ne quittent jamais votre machine Utilisez-le pour créer des jetons de test avec un connu
sub(, une expiration définie ou une expiration délibérément expirée)exppour exercer vos chemins d'erreur API' ; S. Pour lire un jeton en retour, associez-le au Décodeur JWT.
Qu'est-ce qu'un JWT et que produit le générateur ?
Un JSON Web Token est un moyen compact et sûr pour les URL de représenter un ensemble de revendications La structure est définie par la RFC 7519, et la forme signée, qui est ce que presque tout le monde entend par " ; un JWT, " ; est une JSON Web Signature telle que définie par la RFC 7515 Un jeton signé a trois parties jointes par des points : header.payload.signature.
L'en-tête est un petit objet JSON nommant l'algorithme de signature et le type de jeton, quelque chose comme { "alg": "HS256", "typ": "JWT" }. La charge utile est un objet de revendications JSON : qui est le jeton, quand il expire, et quels que soient les champs personnalisés ajoutés par votre application. L'en-tête et la charge utile sont codés en Base64url, qui est une base 64 ordinaire avec deux substitutions de caractères et aucun remplissage, exactement comme le précise la RFC 7515. La signature est un hachage à clé calculé sur les deux premières parties.
Le générateur assemble les trois Vous fournissez la charge utile et le secret, il construit l'en-tête, code les deux segments, calcule la signature et les rejoint. La sortie est une chaîne que vous pouvez déposer directement dans un Authorization: Bearer en-tête, un luminaire de test ou un curl commande.
Une chose qui vaut la peine d'être direct à l'avance : un JWT signé est codé, pas crypté Toute personne qui détient le jeton peut Base64url-décoder la charge utile et lire chaque réclamation de celle-ci La signature ne cache pas le contenu Il prouve seulement que le contenu n'a pas été modifié par quelqu'un sans la clé Ne mettez jamais un mot de passe, une clé API, ou toute autre chose que vous ne montreriez pas à l'utilisateur à l'intérieur d'une charge utile JWT.
Comment fonctionne la signature ?
Pour la famille HMAC, c'est avec quoi cet outil signe, la signature est HMAC(secret, header + "." + payload). HMAC est une construction de hachage à clé définie par la RFC 2104, et la spécification JWA, RFC 7518, y mappe les trois noms d'algorithmes JWT : HS256 utilise HMAC avec SHA-256, HS384 utilise SHA-384 et HS512 utilise SHA-512.
La propriété importante est la symétrie Le même secret crée et vérifie la signature Lorsque votre serveur reçoit un jeton, il recalcule HMAC(secret, header + "." + payload) sur les deux premiers segments reçus et vérifie que le résultat est égal au segment de signature Si un seul octet de la charge utile a été modifié, le hachage recalculé ne correspondra pas et la vérification échoue C'est toute la garantie d'intégrité.
Parce qu'il est symétrique, le secret est tout le jeu Toute personne avec le secret peut frapper des jetons valides pour votre système, c'est pourquoi le générateur exécute la signature dans votre navigateur via l'API Web Crypto et ne transmet jamais le secret nulle part Vous pouvez le confirmer en ouvrant votre navigateur' ; s Onglet Réseau pendant que vous générez un jeton : il n'y a pas de demande Cela compte plus que cela ne sonne, car coller un secret de signature de production en direct dans un outil Web aléatoire que les téléphones à la maison remettraient les clés de votre authentification.
RS256 et ES256, les algorithmes asymétriques, fonctionnent différemment : un signe de clé privée et une clé publique correspondante vérifient Ce sont le bon choix lorsque de nombreux services ont besoin de vérifier des jetons mais qu'un seul devrait pouvoir les émettre Cet outil ne les propose délibérément pas, car signer avec eux signifie coller une clé privée dans une page Web, et c'est une habitude qui vaut la peine de ne jamais commencer.
Comment utiliser le générateur JWT
Étape 1 : Écrivez la charge utile
Entrez vos réclamations en tant qu'objet JSON Un exemple minimal est { "sub": "1234567890", "role": "admin" }. le sub claim est le sujet, généralement un identifiant utilisateur. Vous pouvez ajouter tous les champs personnalisés lus par votre application, tels que role, scope, tenant_id, ou email. L'outil conserve tout ce que vous mettez ici exactement comme écrit.
Étape 2 : Ajoutez les revendications de temps
Laisser émis et les tampons d'outils iat avec le temps Unix actuel Définissez une expiration en secondes pour ajouter un exp claim calculé comme maintenant plus ce décalage Pour un jeton d'accès de quinze minutes, entrez 900. pour un jeton d'une heure, entrez 3600. ce sont les affirmations auxquelles se résument la plupart des bugs d'authentification, donc les faire calculer correctement, en quelques secondes depuis l'époque plutôt qu'en millisecondes, supprime une erreur courante.
Étape 3 : Choisissez l'algorithme et le secret
Choisissez HS256 sauf si vous avez une raison d'utiliser HS384 ou HS512 Entrez le secret de signature dans le champ Choisissez ensuite comment le secret est interprété : le texte brut utilise les octets UTF-8 de ce que vous tapez, tandis que la base64url et l'hex décode la chaîne d'abord en octets bruts Ce choix est important car de nombreux systèmes stockent le secret déjà codé en base64, et si vous alimentez la chaîne codée en texte brut vous allez produire une signature qui ne correspond pas.
Étape 4 : Copiez le jeton
Le JWT signé apparaît avec un aperçu décodé de l'en-tête et de la charge utile afin que vous puissiez confirmer chaque réclamation avant de l'utiliser. Copiez-le et collez-le partout où vous en avez besoin.
Pourquoi générer un jeton à la main ?
Tester votre API' ;s chemin heureux
Lorsque vous écrivez un middleware qui valide les JWT, vous avez besoin d'un jeton que votre code doit accepter Générez-en un signé avec le même secret que celui utilisé par votre vérificateur, avec un valide exp200, et confirmez les retours de requête. Si ce n'est pas le cas, le bug est dans votre logique de vérification, pas dans le jeton. Cette seule étape d'isolation est la raison pour laquelle j'atteins l'outil le plus souvent.
Test des chemins de défaillance
Une API robuste rejette les bons jetons pour les bonnes raisons Générer un jeton avec un exp déjà dans le passé pour confirmer que vous renvoyez la bonne erreur expirée-jeton Générez-en un avec un nbf dans le futur pour tester le chemin pas encore valide Générez-en un signé avec le mauvais secret pour confirmer vos exécutions de vérification de signature Ces cas négatifs sont ceux qui sont expédiés non testés, et un générateur en fait un travail de trente secondes.
Reproduire un bug d'un utilisateur spécifique
Support signale un problème qui ne se produit que pour les comptes avec un rôle particulier Générez un jeton avec ce exact role réclamation et utilisateur concerné' ;s sub1, et vous pouvez reproduire la requête localement sans toucher aux données de production ni demander à l'utilisateur son véritable jeton porteur, ce que vous ne devriez de toute façon jamais faire.
Ensemencement du développement local
Les nouveaux développeurs d'une équipe ont besoin d'un jeton fonctionnel pour atteindre les points de terminaison protégés pendant que l'authentification frontale est encore en cours de construction. Un jeton généré signé avec le secret de développement local les débloque immédiatement.
HS256 vs HS384 vs HS512 : que devez-vous utiliser ?
| algorithme | Hachette | Taille de signature | Longueur minimale de la clé | Quand utiliser |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 octets | 32 octets | La valeur par défaut. Rapide, largement pris en charge, sécurisé pour presque toutes les utilisations |
| HS384 | SHA-384 | 48 octets | 48 octets | Lorsqu'une politique ou une norme exige SHA-384 |
| HS512 | SHA-512 | 64 octets | 64 octets | Contextes de haute sécurité, ou lorsque vous standardisez déjà sur SHA-512 |
La réponse pratique est HS256 sauf si quelque chose d'externe exige le contraire La RFC 7518 exige que la clé soit au moins aussi longue que la sortie de hachage, donc 32 octets pour HS256, 48 pour HS384 et 64 pour HS512 Le générateur avertit lorsque votre secret décodé est plus court que le minimum, car une clé courte affaiblit la signature quel que soit le nom de l'algorithme Un algorithme plus long et plus numéroté ne fixe pas un faible secret ; un secret aléatoire de longueur propre est ce qui compte.
Erreurs courantes et comment les éviter
Le plus fréquent est une inadéquation secrète causée par l'encodage Votre framework stocke le secret comme base64, vous collez la chaîne base64 comme texte brut, et maintenant les octets clés diffèrent de ce que votre vérificateur utilise Les signatures ne correspondent jamais et vous poursuivez un bug fantôme Corrigez-le en choisissant l'encodage secret correct dans l'outil afin que les octets clés bruts soient identiques des deux côtés.
La seconde est constituée de secondes et de millisecondes confuses Les revendications de temps enregistrées dans la RFC 7519 sont toutes mesurées en secondes depuis l'époque Unix. JavaScript' ; s Date.now() renvoie des millisecondes. Si vous calculez exp vous-même et oubliez de diviser par 1000, votre jeton semble expirer dans cinquante mille ans, ce que certains vérificateurs stricts rejetteront. Laisser le générateur calculer les réclamations évite complètement cela.
Le troisième est de traiter la charge utile comme privée Ce n'est pas. Si vous êtes tenté de stocker un secret dans une réclamation, arrêtez. Toute personne possédant le jeton peut le lire. Stockez uniquement ce que vous êtes à l'aise avec le fait que le détenteur du jeton voit et conservez des données véritablement secrètes sur le serveur.
Où les JWT s'adaptent aux autres outils
Une fois que vous avez généré un jeton, l'étape suivante naturelle consiste à le relire Le Décodeur JWT divise n'importe quel jeton en son en-tête et sa charge utile et signale un expiration exp[TRADUCTION], c'est ainsi que vous confirmez que le générateur a produit ce que vous aviez prévu Si vous générez également des secrets, le générateur de hachage calcule SHA hachage côté client et le générateur de mots de passe produit le genre de longue chaîne aléatoire qui rend un bon secret HMAC en premier lieu Si vous voulez comprendre la Base64url étape par la main, le Codeur/décodeur Base64 affiche la même transformation réversible qui transforme l'en-tête et la charge utile en leur forme codée Et lorsque vous avez besoin d'un identifiant aléatoire pour tomber dans un sub ou jti réclamation, le Générateur UUID vous en donne un dans le bon format.
Pour une vision plus large des raisons pour lesquelles les outils basés sur un navigateur maintiennent les éléments sensibles hors des serveurs tiers, le Confidentialité des données dans les outils en ligne guide explique le modèle côté client, et le Boîte à outils pour les développeurs Web rassemble les utilitaires qui se couplent bien avec le travail de jeton.
Comment un serveur vérifie-t-il le jeton que vous générez ?
Il est utile de savoir ce qui se passe de l'autre côté, car cela explique pourquoi le secret et les réclamations doivent être exactement corrects Lorsque votre API reçoit un jeton, une bibliothèque comme jsonwebtoken, jose ou PyJWT fait trois choses dans l'ordre Il divise le jeton sur les points et Base64url-décode l'en-tête pour lire le alg. Il recalcule la signature header.payload en utilisant le secret configuré et le compare, octet pour octet, par rapport au segment de signature Et il vérifie les revendications enregistrées : is exp dans le passé, est nbf à l'avenir, fait iss et aud correspondez à ce que l'API attend.
Chacun de ces contrôles correspond à quelque chose que le générateur vous permet de contrôler Si la vérification échoue sur la signature, le secret ou son encodage diffère entre les deux côtés S'il échoue exp[traduction] ?Le jeton a expiré, ce que vous avez peut-être provoqué exprès pour tester ce chemin S'il échoue alg« , vous avez généré un jeton avec un algorithme que le vérificateur n'est pas configuré pour accepter, ce qui est en soi une chose utile à découvrir. La génération de jetons avec des variations délibérées est la façon dont vous définissez exactement quelle vérification votre API applique et laquelle elle saute silencieusement. ».
Un mot sur le alg en-tête spécifiquement. La RFC 7515 définit none en tant qu'algorithme valide pour un jeton non signé, les premières bibliothèques feraient confiance à un jeton revendiqué alg: none et sauter entièrement la vérification C'est la vulnérabilité JWT classique Les bibliothèques modernes la rejettent par défaut, mais le générateur offre le none option précisément pour que vous puissiez lancer un jeton non signé sur votre API et confirmer qu'il indique non. Si votre API en accepte un jour un, vous avez trouvé un bug sérieux.
Comment devez-vous gérer les secrets et le stockage des jetons ?
Le secret avec lequel vous signez mérite le même soin qu'un mot de passe de base de données Un bon secret HMAC est une longue chaîne aléatoire, pas une phrase mémorable, car la sécurité HMAC dépend de l'inévitable Générer un avec un outil de mot de passe et le stocker dans votre configuration d'environnement, jamais en contrôle source, est la ligne de base Lorsque vous le faites pivoter, rappelez-vous que chaque jeton signé avec l'ancien secret devient invalide au moment où le vérificateur bascule, c'est pourquoi les systèmes de production prennent généralement en charge plus d'un secret valide pendant une fenêtre de rotation.
Du côté client, l'endroit où vous stockez le jeton fini compte autant que la façon dont vous le signez Un jeton en localStorage est lisible par n'importe quel JavaScript de la page, donc une seule faille de script intersite donne à un attaquant un identifiant valide. Un httpOnly, Secure, SameSite le cookie est invisible pour les scripts, ce qui ferme ce chemin au prix d'une protection CSRF. Le modèle courant est un jeton d'accès de courte durée conservé en mémoire et un jeton de rafraîchissement de plus longue durée dans un httpOnly cookie. Rien de tout cela ne change la façon dont vous générez un jeton, mais c'est le contexte qui rend un jeton généré sûr à utiliser plutôt qu'un passif.
FAQ
Comment générer un JWT ?
Collez vos réclamations en tant qu'objet JSON, choisissez un algorithme de signature tel que HS256 et saisissez le secret. L'outil base64url code l'en-tête et la charge utile, calcule la signature HMAC et renvoie le jeton terminé pour que vous puissiez le copier. Tout s'exécute dans votre navigateur.
Quels algorithmes de signature sont pris en charge ?
HS256, HS384 et HS512, la famille HMAC, ainsi qu'un " ; non signé et quot ; option de test. RS256 et ES256 ne sont délibérément pas proposés car ils signent avec une clé privée et coller une clé privée dans une page Web constitue un risque de sécurité qu'il est préférable d'éviter.
Mon secret est-il envoyé à un serveur ?
Non. La signature s'exécute entièrement dans votre navigateur via l'API Web Crypto, de sorte que le secret et la charge utile ne quittent jamais votre appareil. Vous pouvez le confirmer dans l'onglet Réseau DevTools et l'outil continue de fonctionner hors ligne une fois chargé.
Comment puis-je régler l'expiration du jeton ?
Entrez une expiration en quelques secondes et l'outil ajoute un exp claim égal à l'heure courante plus que plusieurs secondes Pour un jeton de quinze minutes entrer 900. laisser le champ vide à omettre exp entièrement.
Pourquoi le secret devrait-il être d'au moins 32 octets ?
La RFC 7518 nécessite une clé HMAC au moins aussi longtemps que la sortie de hachage, qui est de 32 octets pour HS256, 48 pour HS384 et 64 pour HS512. Un secret plus court affaiblit la signature, donc l'outil avertit lorsque le secret décodé est trop court.
Puis-je créer un jeton non signé ?
Oui. Sélectionnez alg none et l'outil produit un en-tête.payload. token avec une signature vide Ceci est uniquement pour tester la façon dont votre API gère les jetons non signés ; la plupart des bibliothèques rejettent alg : aucun par défaut, et vous devriez aussi.
Un JWT généré est-il crypté ?
N° Un JWT signé est codé, pas chiffré : n'importe qui peut base64url-décoder l'en-tête et la charge utile et lire chaque réclamation La signature prouve seulement que le contenu n'a pas été modifié Ne mettez jamais de mots de passe ou de secrets à l'intérieur de la charge utile.
