Un JWT (JSON Web Token) est un standard ouvert défini par la RFC 7519 utilisé en cybersécurité pour authentifier et sécuriser les échanges d’informations entre parties.
Il permet de transmettre des données de manière compacte, sécurisée et vérifiable, en s’appuyant sur des signatures numériques ou un chiffrement pour garantir l’intégrité et, éventuellement, la confidentialité des informations.
Structure d’un JWT
Un JWT se compose de trois parties principales, chacune encodée en Base64URL et séparée par un point (.
) :
-
Header (En-tête)
- Fonction : Définir l’algorithme de signature (par exemple, HS256, RS256, ES256) et indiquer le type de token (généralement « JWT »).
- Exemple :
{"alg": "HS256", "typ": "JWT"}
.
-
Payload (charge utile)
- Fonction : transporter les « claims » ou revendications, c’est-à-dire les informations utiles telles que l’identifiant de l’utilisateur, les rôles, et la date d’expiration.
- Types de claims :
- Registered claims : revendications standardisées comme
iss
(émetteur),exp
(expiration),sub
(sujet) etaud
(audience). - Public claims : revendications pouvant être définies par la communauté ou par l’utilisateur pour des informations partagées.
- Private claims : informations spécifiques à un contexte ou à une application particulière.
- Registered claims : revendications standardisées comme
- Option chiffrement : bien que le payload soit souvent simplement signé (JWS), il peut être chiffré pour une protection supplémentaire via le format JWE (JSON Web Encryption).
-
Signature
- Fonction : assurer l’intégrité du token. La signature est générée en combinant l’en-tête et le payload (préalablement encodés) avec une clé secrète ou une clé privée (pour les algorithmes asymétriques) selon l’algorithme spécifié.
- Exemple : pour HS256, la signature est obtenue via HMAC-SHA256.
👉 Cas d’usage en cybersécurité
- Authentification : une fois l’utilisateur connecté, le serveur génère un JWT que le client inclut dans les requêtes HTTP (par exemple dans l’en-tête
Authorization: Bearer <JWT>
). Cela permet au serveur de vérifier l’identité du client à chaque requête sans nécessiter de stockage de session côté serveur. - Échange d’Informations Sécurisé : dans une architecture microservices ou lors d’interactions entre API, le JWT permet de transmettre des données de manière fiable et sécurisée.
- Single Sign-On (SSO) : facilite le partage de sessions entre plusieurs applications, en centralisant l’authentification grâce à un token unique.
✔ Avantages
- Stateless : aucun stockage côté serveur (contrairement aux sessions).
- Portable : utilisable dans différents contextes (web, mobile, API).
- Compact : format léger, facile à transmettre via URL, en-têtes HTTP ou cookies.
- Flexibles : ils peuvent être utilisés dans divers protocoles et frameworks d’authentification, notamment OAuth2 et OpenID Connect
Risques et bonnes pratiques
🔺 Failles courantes
- Signature non vérifiée : Ne pas vérifier correctement la signature peut permettre à un attaquant de modifier le contenu du token.
- Utilisation d’Algorithmes Faibles : Par exemple, utiliser HS256 avec une clé faible expose à des attaques par force brute.
- Stockage Inadéquat : Stocker le JWT dans des emplacements vulnérables (comme le localStorage) peut entraîner des attaques XSS et le vol de tokens.
- Token Hijacking : En cas d’interception, un token volé peut être utilisé pour usurper l’identité de l’utilisateur.
🟩 Bonnes pratiques
- Utiliser HTTPS : chiffrer toutes les communications pour empêcher l’interception des tokens.
- Choisir des algorithmes robustes : favoriser des algorithmes sécurisés (ex. RSA ou ECDSA) et utiliser des clés suffisamment complexes.
- Limiter la Durée de Vie : définir des dates d’expiration courtes (
exp
) pour réduire le temps de validité du token en cas de compromission. - Valider Systématiquement : vérifier la signature et les claims à chaque utilisation du token.
- Mécanismes de Révocation : mettre en place des stratégies pour invalider les tokens compromis ou expirés.
Exemple de JWT
Différence avec d’autres technologies d’authentification
- JWT vs Session Cookies : les JWT sont autoportants et ne nécessitent pas de stockage côté serveur, contrairement aux cookies de session qui reposent sur une gestion de session.
- JWT vs OAuth2 : OAuth2 est un cadre d’autorisation qui peut utiliser différents formats de token, y compris le JWT, pour transmettre des informations d’authentification.
- JWT vs SAML : alors que SAML (Security Assertion Markup Language) est un standard XML destiné au SSO dans des environnements d’entreprise, le JWT offre un format plus léger et est mieux adapté aux applications web modernes.