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 j'ai 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.
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 valable 14 minutes supplémentaires. Ce qui signifiait que le serveur était bien - et que le bogue devait être sur le client. Effectivement : mon interface vérifiait payload.exp < Date.now(). exp c'est quelques secondes depuis l'époque. Date.now() c'est des millisecondes. Chaque jeton fraîchement frappé semblait avoir expiré quelque part vers 1970, donc le client a "avec efficacité" déconnexion avant que le serveur n'ait eu son mot à dire. Trois caractères de correction — /1000 — Après près de deux heures de chasse.
C'est tout le terrain pour avoir un décodeur JWT dans votre boîte à outils. Un JWT ressemble à un bruit de ligne – trois morceaux de charabia Base64url collés avec des points – mais c'est juste un JSON portant un trench-coat. Au moment où vous pouvez lire les affirmations, la moitié de vos insectes d'authentification cessent d'être des mystères. Mauvaise audience, jeton périmé, rôle manquant, horloge, millisecondes-secondes - ils sont tous assis là en texte brut une fois que vous avez décodé.
Mais - et cela compte - là où vous décodez n'est pas un choix neutre. Un véritable jeton d'accès est un identifiant en direct. Collez-le dans un site de décodeur qui expédie des jetons sur un serveur, et vous venez de déposer une clé de travail de votre API dans les journaux de demande d'un inconnu. C'est la raison 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 l'en-tête, la charge utile et la signature instantanément, traduit instantanément
exp/iatdans les dates humaines et exécute 100 % du côté client afin que le jeton ne quitte jamais votre machine. Une chose à graver en mémoire : le décodage n'est pas une vérification. 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 qu'elle est digne de confiance.
Principales caractéristiques
En-tête, charge utile et fractionnement de signature instantanés
Collez un jeton et le décodeur le divise immédiatement en trois parties : l'en-tête (type d'algorithme et de jeton), la charge utile (vos réclamations) et la signature (encodée à gauche, car il s'agit d'un Mac brut ou d'une signature - il n'y a rien de lisible par l'homme). Pas de bouton de soumission, pas de rechargement de page. Cela reflète exactement ce que votre bibliothèque d'authentification fait en interne avant la vérification : divisez sur ., base64url-décode les deux premiers segments, parse en tant que json. Voir les pièces disposées côte à côte est le moyen le plus rapide de créer une intuition pour le format. Après quelques dizaines de jetons, vous commencerez à reconnaître un jeton RS256 Auth0 par rapport à un jeton HS256 Laravel en un coup d'œil - l'en-tête le révèle à chaque fois.
Horodatages EXP, IAT et NBF lisibles par l'homme
La fonctionnalité la plus utile, point final. exp, iat, et nbf sont des valeurs de date de valeur numérique - secondes depuis l'époque d'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 jeton est toujours en vie, vous obtenez un compte à rebours pour expirer. Cela ressemble à une petite commodité jusqu'à ce que vous déboguiez un 401 intermittent et que vous ayez besoin de répondre "et ce token spécifique était mort lorsque la demande a été déclenchée ? Encore et encore. Comparer le compte à rebours avec le TTL configuré de votre serveur permet également de détecter rapidement une mauvaise configuration. Si vos jetons d'accès sont censés vivre 15 minutes et que le compte à rebours indique 6 jours, votre code d'émission lit la valeur de configuration incorrecte.
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" S'agit-il de luminaires de test ou de quelqu'un qui sonde votre vérificateur - de toute façon, vous voulez le voir immédiatement. Je vérifie d'abord l'en-tête 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 comparez deux jetons, par exemple, un utilisateur qui peut accéder à un point de terminaison et un autre d'un utilisateur qui ne peut pas, la sortie formatée transforme un exercice de plissage en un diff de dix secondes.
100 % côté client : votre jeton ne quitte jamais le navigateur
C'est la fonctionnalité pour laquelle je me bats. Un jeton d'accès collé n'est pas un exemple de données - c'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 un standard - RFC 7519 - donc le décodeur ne se soucie pas de savoir qui a frappé le vôtre. Auth0 et Firebase Tokens avec leurs revendications personnalisées espacées, Laravel Sanctum-adjacentes, Keycloak, SupAbase, AWS Cognito ou les jetons HS256 roulés à la main, mes propres panneaux de backend express pour Toolz.dev - si ce sont trois segments Base64Url rejoints par DOTS, il décode. Cela inclut les JWT malformés : si le deuxième segment n'analysera pas le format JSON, le décodeur vous indique quelle partie est cassée au lieu d'échouer en silence, ce qui est lui-même de diagnostic. Les jetons tronqués sur copie sont plus courants que vous ne le pensez.
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 "porteur"). Ou vérifiez l'application → Stockage local / cookies, car de nombreuses applications y rangent des jetons. Sur le backend, enregistrez-le ou retirez-le de votre suite de tests. Copiez la chaîne entière - un JWT qui perd ses derniers caractères décode mais ne vérifiera jamais, et c'est une heure déroutante dont vous n'avez 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 ê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. Ce n'est pas. Cette vérification de la paranoïa prend dix secondes et c'est exactement ce que je ferais sur l'outil de quelqu'un d'autre.
É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), ainsi que les rôles, les étendues ou les revendications personnalisées que votre pile ajoute. La signature reste encodée, c'est une sortie cryptographique, pas des données. Si l'en-tête 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 configuration de vérificateur - les incompatibilités sont la deuxième cause la plus courante après l'expiration. Et si un horodatage est rendu comme une année à cinq chiffres, félicitations : vous avez trouvé un bogue millisecondes contre seconde, et je vous souhaite la bienvenue 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. (Strict, la variété signée est un JWS par RFC 7515 - il y a un cousin crypté, JWE, mais presque tous les jetons que vous rencontrerez dans la nature sont un JW signé.)
Le mot clé est encodé. Base64URL est un encodage de transport - un moyen réversible de rendre les octets en sécurité des octets - et non le cryptage. Toute personne titulaire d'un JWT peut tout lire dans l'en-tête et la charge utile avec zéro clé, zéro secret, zéro effort. Jouez avec l'encodage brut dans 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 Dates de l'an 56 000 qui n'expirent jamais, ce qui est tranquillement 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 contient également le secret, et toute personne détenant le secret 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 Practices actuels - est brutale : 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 n'inclut pas de 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 affirmations, il ne peut pas – et ne devrait pas prétendre – vous dire que le jeton est authentique. ne 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 qui vous intéressent de lire un attaquant. La charge utile est publique par construction - signée contre la falsification, largement ouverte à la lecture. Si c'est dans le jeton, supposez que tout Internet peut 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 de HTTP. Le serveur a dit non, mais le jeton était-il expiré ? Mauvais public ? Signé avec une clé rassis ? Vous manquez entièrement parce que votre intercepteur n'a pas tiré ? Le décodage du jeton réel à partir de la requête défaillante réduit 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 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 l'intérêt pour 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 un env var a-t-il remplacé à 60 secondes ? Vérifiez ensuite si la fenêtre de 7 jours de la rafraîchissement du jeton est ce que vous pensez que c'est. L'horloge de l'horloge apparaît ici aussi : si l'horloge de votre serveur émettrice fonctionne rapidement, les jetons arrivent déjà anciens au compte du client. Et bien sûr, le bogue de comparaison des secondes contre millisecondes - celui qui a bittoolz.dev - s'annonce dès que vous voyez un parfaitement valide 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 lu les jetons, et cela vaut la peine d'être fait. Décodez un et vous pouvez trouver des adresses e-mail, des noms complets, des URL d'images, des identifiants de locataires - PII chevauchant dans chaque demande d'API, stockées dans LocalStorage et lisibles par tout ce qui met la main sur le jeton. Voici ma position d'opinion, et je vais le discuter avec n'importe qui : ne mettez 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 indique qui vous êtes; l'autorisation dit ce que vous pouvez faire - et lorsque l'autorisation se comporte mal, la réponse se trouve dans les réclamations. L'utilisateur jure qu'il est un administrateur mais qu'il obtient 403 s ? décoder leur jeton. si role dit user, le jeton a été frappé avant la promotion et ils doivent se réinscrire - une conséquence classique des jetons sans état qui transportent des instantanés obsolètes. Si le rôle est présent mais que l'accès échoue toujours, vérifiez le nom et la forme exacts de la demande : 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 la révocation, et aussi proche de rien d'autre possible. Si votre jeton d'actualisation contient des rôles et des données de profil, quelque chose n'est pas le cas : il n'est présenté qu'à un seul point de terminaison et ne devrait pas reproduire le travail du jeton d'accès. Cette vérification côte à côte attrape également la classe de bogues embarrassante où les deux jetons obtiennent accidentellement le même TTL, ce qui transforme votre fenêtre d'accès "15 minutes" en théâtre de sécurité. Demandez-moi comment je sais pour 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 | Difficile - valable jusqu'à exp À moins que vous ne construisiez un denylist, ce qui réintroduit l'état |
Trivial : supprime 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 où vous tenez la clé (public) - 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 d'actualisation de 7 jours est ce 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 de contrôle. Si vous utilisez un monolithe avec une base de données, les sessions simples sont plus simples, plus petites et instantanément révocables - la superpuissance de la vérification distribuée de la JWT résout un problème que vous n'avez pas.
Pendant que nous 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 ?
Uniquement si le décodeur s'exécute côté client. Un véritable jeton est un identifiant en direct - en envoyant à quelqu'un un serveur de planter 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 que vous ne pouvez pas vérifier, utiliser uniquement des jetons de test ou de test.
Pouvez-vous décoder un JWT sans le secret ?
Oui, c'est le point que les gens manquent le plus. L'en-tête et la charge utile sont en code JSON en base64URL et l'encodage n'est pas un cryptage. Tout le monde peut lire chaque réclamation sans aucune clé. Le secret (ou la clé privée) est uniquement nécessaire pour créer ou vérifier la signature. Le décodage ne nécessite rien, la 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 A vraiment réussi - décodez-le et vérifiez la date. Suspects suivants : un jeton tronqué d'un copier-coller bâclé, un 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 standards - techniquement JW, selon la RFC 7515 - sont signés, non cryptés. La signature détecte la falsification mais ne cache rien ; la charge utile est lisible par n'importe qui. Une variante cryptée (JWE) existe mais est rare dans le 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(), qui renvoie des millisecondes - produisant des jetons qui s'annoncent expirés instantanément ou ont des dates d'expiration vers l'an 56 000. Si un horodatage décodé affiche une année à cinq chiffres, c'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, qui convient à un seul service qui émet et vérifie ses propres jetons. RS256 signe avec une clé privée et vérifie avec une clé publique, de sorte que de nombreux services peuvent vérifier sans pouvoir se forger. Règle de base : MONOLITH, HS256, microservices ou fournisseur d'identité tiers, RS256.
arrivée
j'ai construit le Décodeur JWT Parce que je n'arrêtais pas d'en avoir besoin lors de la création de Toolz.dev lui-même - les mêmes jetons d'accès de 15 minutes et les jetons de rafraîchissement de 7 jours que j'ai disséqués tout au long de ce guide. Il décode instantanément, traduit les horodatages qui causent 90 % de la confusion et n'envoient jamais votre jeton nulle part. Cette dernière partie n'est pas une case à cocher pour un outil qui gère les informations d'identification en direct, c'est la conception entière.
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.
