Au printemps dernier, les utilisateurs ont commencé à se déconnecter de Toolz.dev. Pas parfois - constamment Connectez-vous, cliquez sur un outil, boom : retour à l'écran de connexion Le backend émet des jetons d'accès de 15 minutes et des jetons de rafraîchissement de 7 jours, et I' ; d a testé ce flux cent fois Donc naturellement j'ai supposé que le point de terminaison de rafraîchissement était cassé et j'ai passé une heure et quarante minutes à lire le middleware Express qui n'avait rien de mal avec lui.
Ensuite, j'ai finalement fait la chose évidente. J'ai retiré un jeton d'accès en direct de l'en-tête d'autorisation, je l'ai collé dans un décodeur et j'ai regardé les revendications. le exp C'était bien. le iat c'était bien Le jeton était valide encore 14 minutes Ce qui signifiait que le serveur allait bien - et le bug devait être sur le client Assez sûr : mon frontend vérifiait payload.exp < Date.now(). exp c'est quelques secondes depuis l'époque. Date.now() est millisecondes Chaque jeton fraîchement frappé semblait avoir expiré quelque part vers 1970, donc le client " ; utilement" ; a déconnecté tout le monde avant que le serveur n'ait jamais son mot à dire Trois caractères de correctif - /1000- après près de deux heures de chasse.
That' ;s the whole pitch for have a JWT decoder in your toolbox Un JWT ressemble à du bruit de ligne - trois morceaux de charabia base64url collés ensemble avec des points - mais il' ;s just JSON wearing a trench coat Le moment où vous pouvez lire les revendications, la moitié de vos bugs d'authentification cessent d'être des mystères Mauvais public, jeton expiré, rôle manquant, biais d'horloge, millisecondes-vs-secondes - ils' ; sont tous assis juste là en clair une fois que vous décodez.
Mais - et cela compte - où vous décodez n'est pas un choix neutre Un vrai jeton d'accès est un identifiant en direct Collez-le dans un site décodeur qui expédie des jetons à un serveur, et vous' ; venez de déposer une clé de travail de votre API dans un stranger' ; s des journaux de requêtes That' ; est la raison spécifique pour laquelle j'ai construit le Décodeur JWT Toolz.dev Pour fonctionner entièrement dans votre navigateur. Plus d'informations à ce sujet ci-dessous.
tl;dr : Pour décoder un JWT en ligne, collez-le dans le Décodeur JWT Toolz.dev- il divise instantanément l'en-tête, la charge utile et la signature, traduit
exp/iatdans les dates humaines, et s'exécute à 100 % côté client pour que le jeton ne quitte jamais votre machine Une chose à graver dans la mémoire : le décodage n'est PAS vérifiant Un JWT est juste un JSON codé en base64url que tout le monde peut lire - seule la vérification de signature avec la clé prouve que c'est & #39 ; est digne de confiance.
Principales caractéristiques
En-tête, charge utile et fractionnement de signature instantanés
Coller un jeton et le décodeur le brise immédiatement en ses trois parties : l'en-tête (type d'algorithme et de jeton), la charge utile (vos réclamations) et la signature (codée à gauche, car it' ; est un MAC ou une signature brut - there' ; n'a rien de lisible par l'homme là-dedans).Pas de bouton de soumission, pas de rechargement de page Cela reflète exactement ce que fait votre bibliothèque d'authentification en interne avant vérification : scinder sur .(en anglais), base64url-decode the first two segments, parse as JSONVoir les pièces disposées côte à côte est le moyen le plus rapide de construire l'intuition pour le format Après quelques dizaines de jetons, vous' ; commencera à reconnaître un jeton RS256 Auth0 contre un jeton HS256 Laravel en un coup d'œil - l'en-tête le donne à chaque fois.
Horodatages EXP, IAT et NBF lisibles par l'homme
La fonctionnalité la plus utile, point final. exp, iat, et nbf les valeurs NumericDate - quelques secondes depuis l'époque Unix - et personne, moi y compris, ne peut lire 1783430700 Et vous dire si c'est mardi prochain ou la mort par chaleur de l'univers. Le décodeur convertit chaque demande d'horodatage en une date et une heure réelles, dans votre fuseau horaire local et UTC. C'est là que le bogue classique millisecondes-vs-secondes devient instantanément visible : si vous êtes décodé exp Rendu comme une date dans les 56 000 ans, quelqu'un a bourré un JavaScript Date.now() dans un champ qui attend des secondes. J'ai expédié ce bug. Voir la date absurde est le diagnostic. Pour une archéologie plus profonde de l'horodatage, la Convertisseur d'horodatage est à un onglet.
Compte à rebours et statut des expirations
Au-delà du simple rendu de la date, le décodeur vous indique l'état actuel du jeton : valide, expiré ou non encore actif (lorsque nbf est dans le futur). Si le token' ; est toujours en vie, vous obtenez un compte à rebours jusqu'à expiration Cela semble être une petite commodité jusqu'à ce que vous' ; re débogage un 401 intermittent et besoin de répondre à " ; ce jeton spécifique était-il mort lorsque la requête a été déclenchée ?" ; encore et encore Comparaison du compte à rebours contre votre serveur' ; le TTL configuré détecte également les erreurs de configuration rapidement - si vos jetons d'accès sont censés vivre 15 minutes et que le compte à rebours indique 6 jours, votre code émetteur lit la mauvaise valeur de configuration.
Inspection d'algorithmes et d'en-
L'en-tête décodé vous montre alg et typ (plus kid et amis lorsqu'ils sont présents), qui répond à des questions qui comptent pour la sécurité, pas seulement pour le débogage. Ce jeton est-il HS256 ou RS256 ? fait le kid Correspondre à une clé que votre point de terminaison JWK sert réellement ? Et le plus grand : c'est alg quelque chose qu'il ne devrait jamais être, comme none? Revendication des jetons "alg": "none" est-ce que soit les montages de test, soit quelqu'un sonde votre vérificateur - de toute façon, vous voulez le voir immédiatement Je vérifie l'en-tête d'abord sur chaque jeton inconnu, avant de lire une seule réclamation.
Syntaxe-sur les revendications JSON formatées et mises en valeur
Les charges utiles décodées brutes sont des blobs JSON à une seule ligne, et les fournisseurs d'identité adorent les emballer : objets imbriqués, revendications personnalisées espacées de nom, tableaux d'étendues. Le décodeur Pretty-imprime tout avec la syntaxe roles, scope, aud Les tableaux et les objets d'autorisation imbriqués sont réellement scannables. C'est le même traitement que le Formateur JSON donne JSON arbitraire, appliqué automatiquement à vos réclamations Lorsque vous' ; comparer deux jetons - disons, un d'un utilisateur qui peut accéder à un point final et un d'un utilisateur qui peut' ; t - sortie formatée transforme un exercice de plissement en une différence de dix secondes.
100 % côté client - Votre jeton ne quitte jamais le navigateur
C'est la fonctionnalité pour laquelle I' ; d se battent Un jeton d'accès collé n'est pas un échantillon de données - it' ; est un identifiant en direct qui s'authentifie en tant qu'utilisateur réel jusqu'à ce que exp. Tout décodeur qui publie votre jeton sur un backend vient d'écrire une clé de travail dans les journaux de serveurs, les analyses, peut-être un tracker d'erreurs tiers. Le décodeur Toolz.dev effectue tout le décodage en Javascript, dans votre onglet. Rien n'est transmis, rien n'est stocké. Ne me croyez pas sur parole : ouvrez DevTools, regardez l'onglet Réseau, collez un jeton. Aucune demande. J'ai écrit pourquoi cette architecture est importante pour chaque outil d'entrée sensible dans Mon article sur la confidentialité des données dans les outils en ligne.
Fonctionne avec n'importe quel JWT, depuis n'importe quelle pile
Les JWT sont une norme - RFC 7519- donc le décodeur ne le fait pas et n°39 ; peu importe qui a frappé le vôtre. Les jetons Auth0 et Firebase avec leurs revendications personnalisées espacées, les configurations adjacentes à Laravel Sanctum, Keycloak, Supabase, AWS Cognito ou les jetons HS256 laminés à la main sont mes propres signes de backend Express pour Toolz.dev - si c'est le & n°39 ; les trois segments de base64url reliés par des points, cela décode. Cela inclut les presque-JWT mal formés : si le segment deux a gagné et n°39 ; pas analyser comme JSON, le décodeur vous dit quelle partie est interrompue par un diagnostic commun au lieu de vous-t ;
Comment utiliser le décodeur JWT
Étape 1 : Saisissez le jeton
Trouvez le jeton partout où votre application le conserve. Le plus souvent : DevTools → Onglet Réseau → Cliquez sur une demande → Copier le Authorization: Bearer eyJ... valeur d'en-tête (sans le mot " ; Bearer" ;).Ou cochez Application → Local Storage / Cookies, puisque beaucoup d'applications y cachent des jetons Sur le backend, enregistrez-le ou tirez-le de votre suite de test Copiez la chaîne entière - un JWT qui perd ses derniers caractères décode toujours mais ne vérifiera jamais, et que' ; est une heure déroutante que vous ne faites' ; pas besoin.
Étape 2 : Collez-le dans
Ouvrez le Décodeur JWT et coller. Le décodage se produit lorsque vous tapez - pas de bouton Si vous et n°39 ; êtes nerveux à l'idée de coller un jeton de production n'importe où (bon instinct), ouvrez d'abord l'onglet Réseau et confirmez que rien n'est transmis. C'est le n°39 ; t. Ce contrôle de paranoïa prend dix secondes et c'est exactement ce que I' ; a fait sur quelqu'un d'autre' ; outil.
Étape 3 : Lisez les trois parties
En-tête en premier : confirmer alg est ce que votre système attend et typ est JWT. Puis la charge utile : iss (qui l'a frappé), aud (à qui c'est pour), sub (quel utilisateur), plus quels que soient les rôles, les étendues ou les revendications personnalisées ajoutées par votre pile. La signature reste codée - sa sortie cryptographique & #39 ; s, pas les données. Si l'en-tête le dit none, arrêtez-vous et allez vérifier la liste d'autorisation de votre vérificateur avant toute autre chose.
Étape 4 : Vérifiez EXP et les réclamations qui mordent
regarde le décodé exp date et le statut d'expiration. Expiré ? Il y a votre 401. Valable mais rejeté de toute façon ? Maintenant comparer aud et iss contre votre vérificateur' ; s config - les inadéquations il y a la deuxième cause la plus fréquente après l'expiration Et si un horodatage donne comme une année à cinq chiffres, félicitations : vous' ; avez trouvé un bug millisecondes contre secondes, et je vous souhaite la bienvenue par la présente dans un très grand club.
Qu'y a-t-il réellement dans un JWT ? Anatomie des trois parties
Un jeton Web JSON, défini dans la RFC 7519, est composé de trois segments codés en base64URL joints par des périodes : header.payload.signature. (À proprement parler, la variété signée est un JWS selon la RFC 7515 - là et n°39 ; est un cousin crypté, JWE, mais presque tous les jetons que vous et n°39 ; vous rencontrerez dans la nature sont un JWS signé.)
Le mot clé est encodé. Base64url est un codage de transport - un moyen réversible de rendre les octets sûrs pour l'URL - pas un cryptage Toute personne détenant un JWT peut tout lire dans l'en-tête et la charge utile avec zéro clé, zéro secret, zéro effort Jouer avec l'encodage brut dans le Convertisseur de base64 Et vous verrez que c'est l'alphabet standard avec + et / échangé contre - et _, rembourrage tombé. J'ai écrit plus sur l'encodage lui-même dans le Guide d'encodage Base64.
Décodez un en-tête typique et vous obtenez :
{ "alg": "HS256", "typ": "JWT" }
Et une charge utile construite à partir des revendications enregistrées RFC 7519 définit :
{
"iss": "https://toolz.dev",
"sub": "user_8f3a2c",
"aud": "toolz-api",
"exp": 1783431600,
"nbf": 1783430700,
"iat": 1783430700,
"jti": "b4d1f0e2"
}
iss est l'émetteur, sub le sujet (généralement votre identifiant d'utilisateur), aud le public visé, jti Un identifiant de jeton unique. exp, nbf, et iat sont des valeurs numériques : instant Depuis l'époque Unix. Pas de millisecondes. Date.now() Renvoie des millisecondes et confondre les deux produits soit des jetons qui expirent instantanément (mon bogue de déconnexion Toolz.dev) ou des jetons avec exp date de l'an 56 000 qui n'expirent effectivement jamais - ce qui est discrètement l'échec le plus dangereux.
HS256 vs RS256. HS256 signe avec un HMAC sur un secret partagé - rapide, simple, mais chaque service qui vérifie les jetons détient également le secret, et toute personne détenant le secret le peut battre Jetons. Très bien pour un monolithe comme mon backend, où l'émetteur et le vérificateur sont le même processus. RS256 signe avec une clé privée et vérifie avec une clé publique, vous pouvez donc publier la clé publique (via JWK) et laisser une douzaine de microservices vérifier sans qu'aucun d'entre eux ne puisse se forger. Les systèmes distribués et les PDI tiers doivent être sur RS256 ou ses frères et sœurs ECDSA/EDDSA.
le alg: none attaque. La RFC 7519 autorise les JW non garantis lorsque alg est none Et la signature est vide. Les premières bibliothèques ont fait confiance à l'en-tête alg Aveuglément, les attaquants ont dépouillé la signature, mis en place alg à none, et a navigué grâce à la vérification avec des réclamations entièrement contrôlées par l'attaquant. Une astuce connexe échange RS256 pour HS256 afin que le vérificateur utilise le public clé comme secret HMAC C'est pourquoi la RFC 8725 - JSON Web Token Best Current Practices - est franche : le vérificateur doit épingler ses algorithmes autorisés dans le code et ne jamais laisser le jeton choisir Si votre appel de bibliothèque does' ; t inclure un explicite algorithms Liste, corrigez cela aujourd'hui.
Décodage vs vérification - la ligne qui compte. Le décodage, c'est lire, vérifier est de confiance. La différence de code :
// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
Buffer.from(token.split('.')[1], 'base64url').toString()
);
// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });
Un décodeur en ligne fait la première chose Il peut vous montrer les revendications ; il ne peut pas - et ne doit pas faire semblant de - vous dire que le jeton est authentique Seulement verify, avec la clé, fait cela. Ne prenez jamais de décisions d'autorisation sur des réclamations décodées mais non vérifiées.
Ce qui mène à la dernière règle : Ne mettez jamais de secrets dans une charge utile JWT. Pas de mots de passe, pas de clés API, pas de données vous' ; cela vous dérange une lecture d'un attaquant La charge utile est publique par construction - signée contre la falsification, grande ouverte à la lecture. Si c'est le & #39 ; dans le jeton, supposons que tout Internet puisse le voir.
Cas d'utilisation courants
Débogage 401S lors du développement de l'API
Le 401 est le code d'état le moins informatif en HTTP Le serveur a dit non - mais le jeton a-t-il expiré ? Mauvaise audience ? Signé avec une clé périmée ? Manquant entièrement parce que votre intercepteur a fait & #39 ; t feu ? Le décodage du jeton réel de la requête défaillante fait s'effondrer l'espace de recherche en quelques secondes La moitié du temps exp répond seul. l'autre moitié, en comparant iss et aud Contre votre environnement de vérification, la configuration de votre verificateur trouve un jeton de développement rejoué par rapport à la mise en scène, ou vice versa. Je garde le décodeur épinglé à côté de mon client HTTP pour exactement cette boucle ; c'est une entrée de base dans mon Boîte à outils de débogage de l'API. Décodez d'abord, lisez le middleware en second - l'ordre inverse m'a coûté une heure et quarante minutes une fois, et j'ai l'intention de continuer à recueillir des intérêts sur cette leçon.
Expliquer les déconnexions surprises
Lorsque les utilisateurs signalent "la connexion, il ne cesse de me déconnecter", les horodatages du jeton sont votre déclaration de témoin. Décodez un nouveau jeton d'accès et vérifiez l'écart entre iat et exp- est-ce en fait les 15 minutes que vous avez configurées, ou est-ce qu'un env var l'a remplacé à 60 secondes ? Vérifiez ensuite si le jeton de rafraîchissement' ; s fenêtre de 7 jours est ce que vous pensez être Le biais d'horloge apparaît ici aussi : si votre serveur émetteur' ; s horloge tourne quelques minutes vite, les jetons arrivent déjà anciens par le client' ; compte. Et bien sûr, le bug de comparaison secondes contre millisecondes - celui qui bit Toolz.dev - s'annonce au moment où vous voyez un parfait valide bug de comparaison exp Sur un jeton, votre client jure est expiré.
Vérifier ce que votre fournisseur d'identité met dans les jetons
La plupart des équipes n'ont jamais réellement lu les jetons de leurs monnaies IdP, et cela vaut la peine d'être fait. Décodez-en un et vous trouverez peut-être des adresses e-mail, des noms complets, des URL d'image, des identifiants de locataire - des informations personnelles dans chaque requête API, stockées dans localStorage et lisibles par tout ce qui met la main sur le jeton. Here' ; c'est ma position opiniâtre, et I' ; je le discuterai avec n'importe qui : don' ; je ne mets pas d'e-mails d'utilisateur dans les charges utiles JWT. Le sub La revendication existe précisément pour que vous puissiez porter un identifiant opaque et rechercher les détails humains côté serveur. Chaque réclamation supplémentaire est une donnée que vous diffusez et que vous payez pour chaque demande. Décodez, auditez, puis allez rogner les mappages de réclamations de votre IDA.
Vérification des rôles et des étendues lors du débogage d'autorisation
L'authentification dit qui vous êtes ; l'autorisation dit ce que vous pouvez faire - et lorsque l'autorisation se comporte mal, la réponse est dans les réclamations L'utilisateur jure qu'ils' ; sont un administrateur mais obtient des 403 ? décoder leur jeton Si role dit user[TRADUCTION] ?, le jeton a été frappé avant la promotion et ils doivent se reconnecter - une conséquence classique des jetons sans état portant des instantanés périmés Si le rôle est présent mais que l'accès échoue toujours, vérifiez le nom et la forme exacts de la réclamation : roles VS role, tableau vs chaîne, scope En tant que chaîne délimitée par l'espace VS scp comme tableau. Vérification du middleware payload.roles.includes('admin') contre une charge utile qui a role: "admin" échoue silencieusement et de manière exaspérante Deux jetons décodés côte à côte - un fonctionnant, un non - le règlent généralement en moins d'une minute.
Comparaison des accès et actualisation des contenus des jetons
Dans une configuration à double jeton comme le mien, les deux jetons doivent sembler significativement différents, et le décodage des deux est l'audit. Le jeton d'accès : court exp, ainsi que toutes les revendications de l'API ont besoin par demande. Le jeton de rafraîchissement : long exp, un jti pour le suivi de révocation, et aussi près de rien d'autre que possible Si votre jeton de rafraîchissement transporte des rôles et des données de profil, quelque chose' ; est désactivé - it' ; n'est jamais présenté qu'à un seul point final et devrait' ; t dupliquer le jeton d'accès' ; s'emploi Cette vérification côte à côte attrape également la classe de bugs embarrassante où les deux jetons obtiennent accidentellement le même TTL, qui transforme votre fenêtre d'accès " ; 15 minutes" ; en théâtre de sécurité Demandez-moi comment je sais vérifier celui-là.
JWT vs Jetons de session opaques : une comparaison honnête
| JWT | Jeton de session opaque | |
|---|---|---|
| apatride | Autonome ; tout serveur avec la clé vérifie sans recherche | Le serveur (ou le magasin partagé comme Redis) doit rechercher chaque demande |
| révocation | Dur - valable jusqu'à exp À moins que vous ne construisiez un denylist, ce qui réintroduit l'état |
Trivial - supprimez l'enregistrement côté serveur, le jeton meurt instantanément |
| Taille par demande | Des centaines d'octets à plus d'un kilo-octet, sur chaque demander | ~32 à 64 octets |
| Où la validation se produit | Partout, il détient la clé (publique) - idéal pour les microservices | Où vit le magasin de session |
| revendiquer la fraîcheur | Instantané lors de l'émission, les changements de rôle attendent la réédition | Toujours à jour - lit les données en direct |
| débogage | Décoder et lire les revendications instantanément | opaque par la conception; nécessite un accès en magasin |
J'utilise JWTs pour Toolz.dev et je vous dirai toujours qu'ils sont surprescrits. L'histoire de la révocation est vraiment mauvaise : lorsque vous interdisez un utilisateur, son jeton d'accès continue de fonctionner jusqu'à ce que exp- c'est exactement pourquoi mes jetons d'accès vivent 15 minutes et le jeton de rafraîchissement de 7 jours est la chose que je peux tuer côté serveur. Cet hybride est le modèle honnête : des JWT sans état de courte durée pour une vérification bon marché, un point de contrôle avec état pour le contrôle Si vous et n°39 ; exécutez un monolithe avec une seule base de données, les sessions simples sont plus simples, plus petites et instantanément révocables - le JWT' ; La superpuissance de la vérification distribuée résout un problème que vous avez et n°39 ; pas.
Alors que nous et n°39 ; comparons - HS256 vs RS256 en un seul coup d'œil :
| HS256 | RS256 | |
|---|---|---|
| modèle clé | Un signe secret partagé et vérifie | Panneaux de clés privées, clé publique vérifie |
| Qui peut menthe | Quiconque détenait le secret | Seul le détenteur de la clé privée |
| Meilleur ajustement | Service unique, émetteur = vérificateur | Microservices, IDPs tiers, JWK |
| Taille / vitesse de signature | Plus petit, plus rapide | Plus grand, plus lent, plus sûr à distribuer |
Questions fréquentes
Est-il sûr de coller un JWT dans un décodeur en ligne ?
Seulement si le décodeur s'exécute côté client Un vrai jeton est un identifiant en direct - l'envoyer à quelqu'un' ; s serveur plante une clé de travail dans leurs journaux Le décodeur Toolz.dev JWT effectue tout le décodage dans votre navigateur et ne transmet rien ; vous pouvez le confirmer vous-même en regardant l'onglet Réseau pendant que vous collez Pour les décodeurs vous pouvez' ; t vérifier, utiliser les jetons expirés ou de test seulement.
Pouvez-vous décoder un JWT sans le secret ?
Oui - c'est ça & #39 ; c'est le point que les gens manquent le plus L'en-tête et la charge utile sont des JSON codés en base64url, et l'encodage n'est pas un chiffrement N'importe qui peut lire chaque réclamation sans aucune clé Le secret (ou clé privée) n'est nécessaire que pour créer ou vérifier la signature Le décodage ne nécessite rien ; faire confiance nécessite une vérification.
Quelle est la différence entre le décodage et la vérification d'un JWT ?
Le décodage lit le contenu : split sur les points, base64url-decode, analyse json. La vérification de la vérification prouve l'authenticité : recalculez ou vérifiez la signature à l'aide de la clé secrète ou publique, confirmez l'algorithme, vérifiez l'expiration. Un décodeur vous montre ce qu'un token prétend ; seule la vérification, terminée côté serveur avec la clé, vous indique si vous devez y croire. N'autorisez jamais de base sur des revendications décodées mais non vérifiées.
Pourquoi mon JWT est-il invalide ou expiré ?
Le plus souvent, le exp est véritablement passé - décodez-le et vérifiez la date. Suspects suivants : un jeton tronqué provenant d'un copier-coller bâclé, an aud ou iss Cela ne correspond pas à la configuration de votre vérificateur, à l'horloge entre les serveurs ou à une signature à partir d'une clé tournée. Si le décodé exp Cela semble bien, mais votre code rejette le jeton, vérifiez si vous comparez des secondes à des millisecondes.
Les JWT sont-ils cryptés ?
Les JWT standard - techniquement JWS, selon la RFC 7515 - sont signés, non chiffrés La signature détecte la falsification mais ne cache rien ; la charge utile est lisible par n'importe qui Une variante chiffrée (JWE) existe mais est rare dans l'authentification Web typique Règle pratique : traitez chaque charge utile JWT comme publique, et ne mettez jamais de mots de passe, de clés API ou de données sensibles en un seul.
Dans quel format est la réclamation d'EXP ?
exp est une date numérique : secondes depuis l'époque Unix (1er janvier 1970 UTC), telle que définie dans la RFC 7519. Idem pour iat et nbf. Le bug classique utilise JavaScript Date.now()(en), qui renvoie des millisecondes - produire des jetons qui soit semblent expirés instantanément, soit portent des dates d'expiration autour de l'an 56 000. ?Si un horodatage décodé affiche une année à cinq chiffres, ce & #39 ; est votre bug.
Quelle est l'attaque d'ALG None ?
La RFC 7519 permet les JWT non sécurisés avec "alg": "none" et une signature vide. Les anciennes bibliothèques ont fait confiance au champ d'algorithme de l'en-tête, afin que les attaquants aient supprimé les signatures, définis. alg à none, et a passé la vérification avec des réclamations falsifiées. RFC 8725, les meilleures pratiques actuelles de JWT, exige que les vérificateurs épinglent une liste d'algorithmes explicites dans le code et ignorent tout ce que le jeton demande.
Dois-je utiliser HS256 ou RS256 ?
HS256 utilise un secret partagé pour la signature et la vérification - simple et rapide, droit pour un seul service qui émet et vérifie ses propres jetons RS256 signe avec une clé privée et vérifie avec une publique, de sorte que de nombreux services peuvent vérifier sans pouvoir forger la règle de base : monolith, HS256 ; microservices ou fournisseur d'identité tiers, RS256.
arrivée
j'ai construit le Décodeur JWT parce que j'en avais toujours besoin tout en construisant Toolz.dev lui-même - les mêmes jetons d'accès de 15 minutes et jetons de rafraîchissement de 7 jours I' ; j'ai disséqué tout au long de ce guide Il décode instantanément, traduit les horodatages qui causent 90 % de la confusion, et n'envoie jamais votre jeton nulle part Cette dernière partie est & #39 ; pas une case à cocher de fonctionnalité ; pour un outil qui gère les informations d'identification en direct, it& #39 ; c'est toute la conception.
Si les jetons font partie de votre débogage quotidien, les voisins gagneront également leur garde : le Convertisseur d'horodatage Pour l'archéologie d'époque, la Convertisseur de base64 Pour piquer des segments bruts, le Formateur JSON pour les blobs de réclamation, et le générateur de hasch Lorsque vous travaillez avec des résumés. Pour le flux de travail plus large, mon Guide des outils de débogage de l'API Couvre l'endroit où un décodeur s'inscrit dans la boucle.
Et gardez la version à une phrase attachée sur votre moniteur : le décodage vous indique ce que dit un jeton, la vérification vous indique si vous devez le croire. Confondez les deux et vous enverrez le genre de bogue qui finit par être l'anecdote d'ouverture dans le billet de blog de quelqu'un. Cette fois, c'était le mien.
