Dans cet article
Qu'est-ce qu'un JWT ?
Un JSON Web Token (JWT) est un format de jeton compact et compatible URL utilise pour transmettre des informations de maniere securisee entre les parties sous forme d'objet JSON. Un JWT se compose de trois parties encodees en Base64URL separees par des points : en-tete.charge-utile.signature. L'en-tete specifie l'algorithme de signature, la charge utile contient les revendications (donnees), et la signature verifie que le jeton n'a pas ete altere.
Les JWT permettent l'authentification sans etat — le serveur n'a pas besoin de stocker des donnees de session car toutes les informations necessaires sont integrees dans le jeton lui-meme. Cela rend les JWT ideaux pour les systemes distribues, les microservices et les API ou le stockage de session ajouterait de la complexite et de la latence.
Structure d'un JWT expliquee
Chaque JWT est compose de trois parties distinctes, chacune ayant un role specifique dans le cycle de vie du jeton :
- En-tete (Header) — un objet JSON specifiant le type de jeton (typ: JWT) et l'algorithme de signature (alg: HS256, RS256, etc.), puis encode en Base64URL
- Charge utile (Payload) — un objet JSON contenant des revendications telles que iss (emetteur), sub (sujet), exp (expiration), iat (date d'emission), et toute donnee personnalisee que vous souhaitez transmettre
- Signature — creee en signant l'en-tete et la charge utile encodes avec une cle secrete (HMAC) ou une cle privee (RSA/ECDSA), assurant l'integrite du jeton
La charge utile n'est pas chiffree — n'importe qui peut la decoder et la lire. Ne stockez jamais d'informations sensibles comme des mots de passe ou des numeros de carte de credit dans la charge utile d'un JWT. La signature garantit uniquement que les donnees n'ont pas ete modifiees, pas qu'elles sont cachees.
Algorithmes de signature
Le choix de l'algorithme de signature determine comment la signature JWT est creee et verifiee. Il existe trois grandes familles d'algorithmes :
- HMAC (HS256, HS384, HS512) — algorithmes symetriques qui utilisent la meme cle secrete pour la signature et la verification. Simples a implementer, ideaux pour les configurations a serveur unique ou l'emetteur et le verificateur partagent le meme secret
- RSA (RS256, RS384, RS512) — algorithmes asymetriques utilisant une cle privee pour signer et une cle publique pour verifier. Ideaux pour les systemes distribues ou plusieurs services doivent verifier les jetons sans avoir acces a la cle de signature
- ECDSA (ES256, ES384, ES512) — algorithmes asymetriques utilisant la cryptographie sur courbes elliptiques. Offrent la meme securite que RSA avec des tailles de cles nettement plus petites et un calcul plus rapide, bien adaptes aux applications mobiles et IoT
Pour la plupart des applications web, HS256 suffit lorsque l'emetteur et le consommateur du jeton sont le meme serveur. Choisissez RS256 ou ES256 lorsque les jetons doivent etre verifies par des tiers ou entre differents services.
Essayez gratuitement — sans inscription
Creer et signer des JWT →Encodage vs Decodage
Encoder un JWT signifie creer un nouveau jeton en assemblant l'en-tete, la charge utile et en generant la signature avec votre cle secrete ou privee. Cela se fait generalement cote serveur lors de la connexion ou du renouvellement du jeton. La chaine de jeton resultante est envoyee au client pour les requetes authentifiees suivantes.
Decoder un JWT peut signifier deux choses : extraire les revendications de la charge utile sans verifier la signature (utile pour lire les metadonnees du jeton cote client), ou verifier completement la signature pour confirmer que le jeton est authentique et non altere. Les systemes en production doivent toujours verifier la signature avant de faire confiance aux revendications de la charge utile.
Cas d'utilisation courants
Les JWT sont devenus la norme pour les modeles modernes d'authentification et d'autorisation dans les applications web et mobiles :
- Authentification API — les clients incluent le JWT dans l'en-tete Authorization (Bearer token) a chaque requete, permettant au serveur de verifier l'identite sans consultation de base de donnees
- Jetons d'acces OAuth 2.0 — les fournisseurs OAuth emettent des JWT comme jetons d'acces contenant les informations de portee et de permission pour l'acces API autorise
- Communication entre microservices — les services se transmettent des JWT pour propager l'identite utilisateur et les permissions a travers les frontieres de service sans stockage de session centralise
- Authentification unique (SSO) — un fournisseur d'identite central emet un JWT que plusieurs applications acceptent, permettant aux utilisateurs de s'authentifier une seule fois et d'acceder a tous les services connectes
Bonnes pratiques de securite
Les JWT sont puissants mais necessitent une implementation soignee pour eviter les pieges de securite courants :
- Definir des durees d'expiration courtes — utilisez des revendications exp de 15 minutes a 1 heure pour les jetons d'acces, et implementez la rotation des jetons de rafraichissement pour les sessions plus longues
- Ne jamais stocker de donnees sensibles dans la charge utile — les charges utiles JWT sont seulement encodees en Base64URL, pas chiffrees. Quiconque possede le jeton peut lire les revendications
- Toujours valider toutes les revendications — verifiez exp, iss, aud et toute revendication personnalisee a chaque requete. Ne faites pas confiance a la charge utile sans verification complete de la signature
- Utiliser exclusivement HTTPS — transmettez les JWT uniquement via des connexions chiffrees pour empecher l'interception des jetons par des attaques de type homme du milieu
- Rejeter l'algorithme "none" — validez toujours que l'en-tete alg correspond a votre algorithme attendu. L'algorithme "none" contourne entierement la verification de la signature
Questions frequemment posees
Quelle est la difference entre JWT et les cookies de session ?
Les cookies de session stockent un identifiant de session sur le client tandis que les donnees de session reelles resident sur le serveur. Les JWT sont autonomes — toutes les donnees sont dans le jeton lui-meme. Cela rend les JWT sans etat et plus faciles a mettre a l'echelle horizontalement, mais plus difficiles a revoquer puisqu'on ne peut pas simplement supprimer une session cote serveur. Les cookies de session sont plus simples pour les applications web traditionnelles ; les JWT sont meilleurs pour les API et les systemes distribues.
Comment revoquer un JWT avant son expiration ?
Puisque les JWT sont sans etat, il n'y a pas de mecanisme de revocation integre. Les strategies courantes incluent : maintenir une liste noire de jetons (verification a chaque requete), utiliser des jetons d'acces a courte duree avec rotation des jetons de rafraichissement (la revocation du jeton de rafraichissement invalide les acces futurs), ou stocker une version de jeton dans l'enregistrement utilisateur et l'incrementer a la deconnexion.
Y a-t-il une limite de taille pour les JWT ?
Il n'y a pas de limite de taille formelle dans la specification JWT, mais des limites pratiques existent. La plupart des serveurs HTTP limitent la taille des en-tetes a 8 Ko. Comme les JWT sont generalement envoyes dans l'en-tete Authorization, il est recommande de garder les jetons en dessous de 4 Ko. Les charges utiles volumineuses avec de nombreuses revendications peuvent depasser cette limite — envisagez de ne stocker que les revendications essentielles dans le JWT et de recuperer les donnees supplementaires via une API.