Comment decoder un JWT (et pourquoi decoder n'est pas verifier)

Vous deboguez un flux d’authentification et quelqu’un vous tend une longue chaine de caracteres incomprehensibles : eyJhbGciOi.... C’est un JSON Web Token, ou JWT, et a l’interieur se trouvent des donnees structurees que vous pouvez lire en quelques secondes une fois que vous savez comment. Ce guide explique de quoi est fait un JWT, comment le decoder pour inspecter ses claims et le point de securite qui trompe constamment les developpeurs : decoder un token n’est pas la meme chose que le verifier. Vous pouvez suivre avec le Decodeur de JWT gratuit.

De quoi est fait un JWT

Un JWT est un moyen compact de transporter des informations signees entre deux parties, le plus souvent pour prouver qui est un utilisateur apres sa connexion. En regardant de pres, vous verrez qu’il est divise en trois parties separees par des points :

header.payload.signature

Chacune des deux premieres parties est un objet JSON encode en Base64url, ce qui explique pourquoi cela ressemble a des caracteres aleatoires plutot qu’a du texte lisible. Les trois elements sont :

• Header (en-tete). Petit JSON decrivant le token, principalement l’algorithme de signature (comme HS256 ou RS256) et le type de token.
• Payload (charge utile). La partie interessante. Elle contient les claims : qui est l’utilisateur, quand le token a ete emis, quand il expire et toute donnee personnalisee ajoutee par l’emetteur.
• Signature. Un cachet cryptographique cree a partir de l’en-tete, de la charge utile et d’une cle secrete. C’est ce qui permet a un serveur de confirmer que le token n’a pas ete altere.

Les points sont des separateurs litteraux, donc un JWT est toujours constitue de trois blocs Base64url joints par des points.

Comment decoder et lire les claims

Decoder inverse simplement l’encodage Base64url de l’en-tete et de la charge utile afin que vous puissiez lire le JSON a l’interieur. Le Decodeur de JWT gratuit fait cela instantanement et, point important, s’execute entierement dans votre navigateur, de sorte que le token que vous collez n’est jamais envoye nulle part.

1. Copiez le token complet, les trois parties y compris les points.
2. Collez-le dans le Decodeur de JWT.
3. Lisez l’en-tete et la charge utile decodes sous forme de JSON formate.

Dans la charge utile, vous verrez souvent des claims standard : sub pour le sujet (generalement un identifiant utilisateur), iat pour l’heure d’emission, exp pour l’expiration et iss pour l’emetteur. Les valeurs temporelles sont generalement des horodatages Unix. Les lire est le moyen le plus rapide de repondre a des questions comme ‘ce token est-il expire ?’ ou ‘pour quel utilisateur est-il ?’ pendant le debogage.

Decoder n’est pas verifier

Voici le point qui merite d’etre grave dans votre memoire. Quiconque possede le token peut decoder l’en-tete et la charge utile, sans cle ni mot de passe. L’encodage est reversible par conception, exactement comme Base64. Decoder vous dit ce que le token affirme, mais ne vous dit rien sur la fiabilite de ces affirmations.

Verifier est une etape distincte et cryptographique. Un serveur recalcule la signature en utilisant la cle secrete ou publique et verifie qu’elle correspond a la signature du token. Seule une signature valide prouve que le token a ete emis par celui qu’il indique et qu’il n’a pas ete modifie. Un decodeur ne peut pas faire cela pour vous, car il ne possede pas la cle. Ne decidez donc jamais que ‘cet utilisateur est authentifie’ sur la base d’un simple decodage, cette verification doit avoir lieu sur le serveur avec la cle appropriee.

Ne mettez jamais de secrets dans la charge utile

Comme la charge utile est trivialement lisible par quiconque detient le token, c’est le mauvais endroit pour tout element sensible. Ne mettez pas de mots de passe, de cles d’API ni de donnees personnelles privees dans la charge utile d’un JWT, car elle est de fait publique pour quiconque intercepte ou recoit le token. La signature empeche l’alteration, pas la lecture. Considerez la charge utile comme visible par defaut et gardez les secrets cote serveur.

Outils connexes pour inspecter les tokens

Le decodage d’un JWT mene souvent a quelques taches voisines. Si vous voulez comprendre la couche Base64url elle-meme, l’outil d’encodage et de decodage Base64 vous permet d’experimenter avec le meme encodage que celui utilise par le token. Une fois que vous avez une charge utile decodee, le Formateur JSON l’indentera et la rangera afin qu’un ensemble de claims profondement imbrique soit facile a parcourir. Et si vous reflechissez a la facon dont la signature est construite, le Generateur de Hash est un bon moyen de voir comment se comporte le hachage a sens unique, car la signature repose sur des primitives cryptographiques connexes.

La version courte

Un JWT est constitue de trois parties encodees en Base64url, l’en-tete, la charge utile et la signature, jointes par des points. Decoder inverse l’encodage pour que vous puissiez lire les claims, ce qui est parfait pour le debogage. Souvenez-vous simplement que decoder n’est pas verifier : la charge utile est lisible par n’importe qui, donc n’y stockez jamais de secrets, et verifiez toujours la signature sur le serveur avant de faire confiance a un token. Lorsque vous devez en inspecter un rapidement et en toute confidentialite, le Decodeur de JWT gratuit le lit directement dans votre navigateur.