Un jeton JWT, abréviation de JSON Web Token, est un format compact pour passer des revendications entre deux parties. Les applications utilisent couramment les JWT après la connexion : un serveur émet un jeton, le client l'envoie avec les requêtes ultérieures, et une API vérifie le jeton avant d'autoriser l'accès. Un JWT n'est pas un jeton de cryptomonnaie, et son contenu n'est pas automatiquement secret.
Les systèmes de compte dans la finance, les échanges et les services Web3 peuvent utiliser l'authentification par jeton en coulisses. Les lecteurs explorant les plateformes d'actifs numériques peuvent créer un compte Tapbit, tandis que les développeurs doivent traiter chaque jeton d'authentification comme une information d'identification sensible à la sécurité.
Qu'est-ce qu'un jeton JWT ?
La norme JWT, RFC 7519, définit un format de revendications compact conçu pour être transmis sous forme d'objet JSON. Une revendication est une déclaration telle qu'un identifiant d'utilisateur, l'émetteur du jeton, l'audience prévue ou l'heure d'expiration. Les JWT sont souvent utilisés comme jetons d'accès, jetons d'identité ou messages de courte durée entre services.
On dit souvent « jeton JWT », bien que le dernier « T » signifie déjà jeton. La répétition est courante et inoffensive. Ce qui importe, c'est de comprendre que JWT décrit un format, pas un système de connexion complet. Une authentification sécurisée nécessite également des politiques correctes d'émission, de validation, de stockage, d'expiration et de révocation.
Comment fonctionne un jeton Web JSON ?
Un flux de connexion typique commence lorsqu'un utilisateur soumet des informations d'identification valides. Le serveur d'authentification crée un JWT contenant des revendications sélectionnées et le protège avec une signature numérique ou un code d'authentification de message. Le client présente ensuite le JWT à une API, souvent dans un en-tête d'autorisation HTTP en utilisant le schéma Bearer.
L'API vérifie la signature et les revendications requises avant de faire confiance à la requête. Les vérifications importantes peuvent inclure l'émetteur, l'audience, l'heure d'expiration et l'algorithme attendu par l'application. Si la vérification réussit, l'API utilise les revendications pour prendre une décision d'autorisation. Si elle échoue, la requête doit être rejetée.
Les trois parties d'un JWT
Un JWT signé couramment vu a trois sections encodées en Base64url séparées par des points :
header.payload.signature
- En-tête : identifie le type de jeton et l'algorithme de signature.
- Charge utile : contient les revendications, telles que
subpour le sujet,isspour l'émetteur,audpour l'audience etexppour l'expiration. - Signature : permet au destinataire de détecter les modifications non autorisées et de vérifier le signataire lorsque la clé correcte est utilisée.
L'encodage Base64url n'est pas un chiffrement. Toute personne qui obtient un JWT signé normal peut généralement décoder son en-tête et sa charge utile. Les informations sensibles ne doivent donc pas être placées dans la charge utile, sauf si le système utilise un format chiffré approprié et en a un besoin clair.
Exemple de JWT pour débutants
Considérez une API qui émet un jeton après qu'Alice se soit connectée. Sa charge utile pourrait identifier Alice comme sujet, nommer l'émetteur, spécifier l'audience de l'API et expirer dans 15 minutes. Lorsque Alice demande son profil, l'API valide le jeton et utilise la revendication du sujet pour localiser le bon compte.
Si quelqu'un modifie la charge utile de l'identifiant d'Alice à celui d'un administrateur, la signature ne correspondra plus. C'est l'avantage principal d'un JWT signé : la falsification devient détectable. Une signature valide ne prouve pas que chaque revendication est appropriée, cependant. L'API doit toujours confirmer que le jeton provient de l'émetteur attendu et était destiné à cette API.
JWT vs Cookies de session vs Clés API
| Méthode | Objectif typique | Où réside l'état | Considération principale |
|---|---|---|---|
| JWT | Revendications et autorisation API | Le jeton transporte les revendications ; les serveurs peuvent toujours conserver l'état | Conception de la validation et de la révocation |
| Cookie de session | Session de connexion du navigateur | Généralement un magasin de session côté serveur | Protections des cookies et CSRF |
| Clé API | Identifier une application ou un projet | Le serveur associe la clé aux permissions | Les clés sont des secrets à longue durée de vie sauf si elles sont renouvelées |
Les JWT ne sont pas automatiquement meilleurs que les sessions. Les sessions peuvent rendre la révocation immédiate simple, tandis que les JWT peuvent réduire les recherches répétées dans la base de données et bien fonctionner entre les services distribués. De nombreux systèmes combinent les deux approches, comme un JWT de courte durée avec un enregistrement de jeton de rafraîchissement géré par le serveur.
Les JWT sont-ils chiffrés ?
Généralement non. Le JWT familier en trois parties est couramment un objet JSON Web Signature signé. La signature assure l'intégrité et l'authenticité lorsqu'elle est correctement implémentée, mais elle ne masque pas la charge utile. JSON Web Encryption est une norme connexe qui peut fournir la confidentialité, bien qu'elle utilise une structure différente et ajoute de la complexité de gestion des clés.
Cette distinction est importante car les développeurs collent parfois un JWT dans un décodeur et sont surpris de voir des données lisibles. Le décodage n'est pas la même chose que la vérification réussie de la signature. Les applications ne devraient jamais accorder l'accès uniquement sur la base des revendications décodées.
Risques de sécurité courants des JWT
Les Bonnes pratiques JWT de l'IETF, RFC 8725, abordent les échecs d'implémentation qui sont apparus dans les systèmes réels. Les problèmes les plus importants proviennent généralement d'une validation incorrecte plutôt que du format de base lui-même.
- Confusion d'algorithme : acceptation d'un algorithme inattendu ou non sécurisé.
- Vérifications de revendications manquantes : ignorance de l'émetteur, de l'audience, de l'expiration ou d'autres exigences de l'application.
- Vol de jeton : exposition d'un jeton porteur via des journaux, des scripts, un stockage non sécurisé ou un transport non protégé.
- Clés faibles : utilisation de secrets devinables ou échec de rotation des clés de signature compromises.
- Longue expiration : laisser les jetons volés utiles trop longtemps.
- Mauvaise révocation : présumer qu'un jeton signé ne peut jamais avoir besoin d'une invalidation anticipée.
Bonnes pratiques JWT
Les applications doivent explicitement n'autoriser que les algorithmes qu'elles prennent en charge, vérifier chaque revendication requise et utiliser des règles de validation distinctes pour différents types de JWT. Les jetons doivent être de courte durée, transmis uniquement via HTTPS et exclus des URL et des journaux de routine. Les clés de signature nécessitent un stockage sécurisé, une rotation et une propriété claire.
Le stockage dépend de l'application. Les systèmes de navigateur peuvent utiliser des cookies sécurisés, HttpOnly et SameSite, tandis que les clients mobiles ou backend utilisent un stockage protégé approprié à la plateforme. Aucun choix de stockage ne supprime toutes les menaces, les développeurs doivent donc considérer ensemble le cross-site scripting, le cross-site request forgery, la relecture de jeton et le compromis de l'appareil.
Conclusion
Un JWT est un moyen compact de transporter des revendications vérifiables entre les systèmes. Son en-tête décrit comment il est protégé, sa charge utile contient des revendications et sa signature aide les destinataires à détecter les falsifications. Les JWT peuvent simplifier l'authentification API, mais seulement lorsque le destinataire vérifie le bon algorithme, l'émetteur, l'audience, les revendications temporelles et la signature. Pour les débutants, la règle clé est simple : un JWT est un format d'identification, pas une preuve qu'une conception d'authentification entière est sécurisée.
Questions fréquemment posées
Que signifie JWT ?
JWT signifie JSON Web Token, un format compact standardisé pour transmettre des revendications sous forme de JSON.
Quelqu'un peut-il décoder un JWT ?
Toute personne possédant un JWT signé typique peut généralement décoder son en-tête et sa charge utile. Le décodage ne vérifie pas la signature et ne rend pas les revendications fiables.
Un JWT est-il la même chose qu'un jeton d'accès ?
Non. Un jeton d'accès décrit un objectif, tandis qu'un JWT décrit un format. Certains jetons d'accès sont des JWT, d'autres sont des chaînes opaques.
Combien de temps un JWT doit-il durer ?
Il n'y a pas de durée universelle. Les jetons d'accès sont généralement de courte durée, la durée exacte dépendant des exigences du système en matière de risque, de révocation et d'utilisabilité.
Un JWT peut-il être révoqué ?
Oui, mais la révocation nécessite une conception supplémentaire, telle qu'une liste noire, une rotation des clés, un versionnage des jetons ou un système de jetons de rafraîchissement géré par le serveur.
