JWT expliqué : comment fonctionnent les jetons Web JSON

Les jetons Web JSON (JWT) sont omniprésents dans l'authentification Web moderne : connectez-vous à presque toutes les applications et un JWT est probablement impliqué. Pourtant, ils sont largement mal compris, et ce malentendu conduit à de véritables erreurs de sécurité. Voici comment ils fonctionnent réellement, en termes simples.

Qu'est-ce qu'un JWT

Un JWT est un jeton compact et autonome qui contient des informations (« revendications ») sur un utilisateur ou une session. Une fois connecté, un serveur vous délivre un JWT ; vous le renvoyez à chaque demande et le serveur lui fait confiance car il est signé cryptographiquement. C'est un moyen de prouver "Je suis authentifié" sans que le serveur ne stocke l'état de la session.

Les trois parties

Un JWT est constitué de trois sections codées en Base64URL séparées par des points : header.payload.signature.

• En-tête : le type de jeton et l'algorithme de signature.
• Charge utile : les revendications : ID utilisateur, rôles, heure d'expiration, etc.
• Signature : un sceau cryptographique prouvant que le jeton n'a pas été falsifié.

Collez n'importe quel jeton dans notre décodeur JWT pour voir ces parties disposées. La norme est définie dans la RFC 7519.

La mise en garde cruciale en matière de sécurité

Voici l'erreur que font les gens : l'en-tête et la charge utile sont uniquement codés en Base64, et non chiffrés. Quiconque intercepte un JWT peut décoder et lire la charge utile instantanément. Ne mettez donc jamais de secrets (mots de passe, données personnelles sensibles) dans une charge utile JWT. La signature empêche la falsification, mais pas la lecture. (Consultez notre guide sur pourquoi Base64 n'est pas une sécurité.)

Comment la signature vous protège

Le serveur signe le jeton avec une clé secrète. Si quelqu'un modifie la charge utile, la signature ne correspond plus et le serveur la rejette. C'est ce qui permet au serveur de faire confiance à un jeton qu'il n'a pas stocké : il peut vérifier mathématiquement son authenticité.

L'expiration est importante

Étant donné que les JWT sont autonomes, vous ne pouvez pas facilement en « révoquer » un avant son expiration. C'est pourquoi les jetons bien conçus incluent une expiration courte (la revendication exp) et les applications utilisent des jetons d'actualisation pour en émettre de nouveaux. Les JWT de longue durée constituent un risque pour la sécurité.

Algorithmes de signature : HMAC vs RSA

L'en-tête indique comment un jeton est signé, et il existe deux familles communes. HMAC (par exemple HS256) utilise un seul secret partagé pour signer et vérifier : c'est simple, mais chaque partie qui vérifie doit détenir le secret. RSA/ECDSA (par exemple RS256) utilise une clé privée pour signer et une clé publique distincte pour vérifier, vous pouvez donc laisser de nombreux services vérifier les jetons sans jamais partager le secret de signature. Pour les systèmes distribués, la signature asymétrique est généralement le choix le plus sûr ; pour un seul backend, HMAC convient.

Où stocker un JWT dans le navigateur

Une question de sécurité pratique : où se trouve le jeton côté client ? localStorage est pratique mais lisible par n'importe quel JavaScript, ce qui le rend vulnérable aux attaques XSS qui volent le jeton. Un cookie HttpOnly ne peut pas être lu par JavaScript, ce qui atténue XSS, mais nécessite une protection CSRF. Il n'y a pas de réponse parfaite — c'est un compromis — mais stocker des jetons sensibles dans un simple localStorage sur un site présentant un risque XSS est une arme connue qui vaut la peine d'être évitée.

La vulnérabilité "alg: none"

Un célèbre piège de JWT : certaines bibliothèques acceptaient historiquement les jetons avec l'algorithme défini sur "aucun", ce qui signifie aucune signature - permettant aux attaquants de falsifier n'importe quelle charge utile de leur choix. La leçon est de toujours vérifier la signature avec un algorithme explicite et attendu, et de ne jamais faire confiance à l'algorithme déclaré par le jeton lui-même. Utilisez une bibliothèque bien entretenue, épinglez l'algorithme et un JWT reste un identifiant robuste et inviolable.

Résultat

Un JWT est un jeton signé et autonome composé de trois parties Base64URL : en-tête, charge utile et signature. La signature garantit l'intégrité, mais la charge utile est lisible par n'importe qui : gardez donc les secrets à l'écart, définissez des expirations courtes et décodez les jetons avec un outil lorsque vous avez besoin de les inspecter.