Qu'est-ce que le JWT ? Guide complet des JSON Web Tokens

Qu'est-ce que le JWT ?

JSON Web Token (JWT) est une norme ouverte (RFC 7519) qui définit un moyen compact et autonome de transmettre de manière sécurisée des informations entre des parties sous forme d'objet JSON. Les JWT sont le format de jeton dominant dans les applications web modernes, utilisés pour tout, de l'authentification des utilisateurs et de l'autorisation des API à l'échange sécurisé de données entre microservices.

Comment fonctionne l'authentification JWT

L'authentification JWT suit un modèle sans état (stateless) qui élimine le besoin de stockage de session côté serveur. Comprendre ce flux est essentiel pour comprendre pourquoi les JWT sont devenus le choix par défaut pour la sécurité des API modernes.

Le flux d'authentification

1. L'utilisateur se connecte — Le client envoie les identifiants (nom d'utilisateur et mot de passe) au serveur d'authentification.
2. Le serveur crée un JWT — Le serveur valide les identifiants, crée un JWT contenant l'identité et les permissions de l'utilisateur, le signe avec une clé secrète ou privée, puis le renvoie au client.
3. Le client stocke le jeton — Le client stocke le JWT, généralement dans localStorage, sessionStorage ou un cookie HTTP-only.
4. Le client envoie le jeton avec chaque requête — Pour chaque requête API suivante, le client inclut le JWT dans le header Authorization en utilisant le schéma Bearer : Authorization: Bearer <token>.
5. Le serveur vérifie le jeton — Le serveur vérifie la signature du JWT, contrôle l'heure d'expiration et extrait les revendications de l'utilisateur pour autoriser la requête.
6. Aucune consultation de session requise — Comme le JWT contient toutes les informations nécessaires, le serveur n'a pas besoin d'interroger une base de données ou un cache pour identifier l'utilisateur.

Pourquoi c'est important

L'authentification traditionnelle basée sur les sessions stocke les identifiants de session dans la mémoire ou la base de données du serveur. Chaque requête authentifiée nécessite une consultation. Les JWT éliminent cette consultation — le jeton lui-même prouve l'identité de l'utilisateur. Cela rend les systèmes basés sur JWT intrinsèquement évolutifs, car n'importe quel serveur d'un cluster peut vérifier un jeton sans état de session partagé.

JWT vs authentification par session

| Aspect | Authentification JWT | Authentification par session | |--------|--------------------|------------------------------| | Stockage | Côté client (dans le jeton) | Côté serveur (en mémoire ou en base de données) | | Évolutivité | Aucun stockage de session partagé nécessaire | Nécessite un stockage de session partagé entre les instances | | Multi-domaine | Fonctionne naturellement entre domaines | Difficile de partager les sessions | | Adapté au mobile | Oui (aucun cookie requis) | Nécessite la prise en charge des cookies | | Révocation | Difficile (jusqu'à l'expiration du jeton) | Facile (supprimer la session du stockage) | | Taille du payload | Plus grande par requête (jeton dans le header) | Minimale (uniquement l'ID de session) |

Pourquoi JWT est utilisé pour la sécurité des API

Les caractéristiques qui rendent JWT adapté à l'authentification le rendent également idéal pour sécuriser les API.

Sans état et évolutif

Chaque JWT contient toutes les informations dont le serveur a besoin pour autoriser une requête. Il n'y a pas de base de données de sessions à interroger, pas de cache à vérifier, pas d'état à synchroniser entre les serveurs. Les répartiteurs de charge (load balancers) peuvent acheminer les requêtes vers n'importe quelle instance de serveur sans coordination.

Multi-domaine et multi-origine

JWT fonctionne naturellement entre différents domaines et origines. Un jeton émis par auth.example.com peut être utilisé pour accéder à api.example.com et admin.example.com. Cela fait de JWT le fondement des systèmes d'authentification unique (SSO).

Autorisation granulaire

Le payload JWT peut inclure des revendications personnalisées pour les rôles, les permissions et les appartenances à des organisations :

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

Le serveur API lit ces revendications directement depuis le jeton, sans consultation supplémentaire.

JWT pour l'authentification unique (SSO)

L'authentification unique est l'un des cas d'utilisation JWT les plus courants. Dans une architecture SSO typique :

1. Un utilisateur se connecte au fournisseur d'identité (IdP) — comme Auth0, Okta ou Keycloak.
2. L'IdP émet un JWT signé avec sa clé privée.
3. L'utilisateur présente ce JWT à plusieurs applications.
4. Chaque application vérifie la signature à l'aide de la clé publique de l'IdP.
5. Chaque application fait confiance au jeton sans communiquer avec l'IdP à chaque requête.

Ce modèle permet à une seule connexion d'accorder l'accès à des dizaines de services — e-mail, stockage de fichiers, gestion de projet, systèmes RH — sans que chaque service n'implémente son propre flux de connexion.

Bonnes pratiques de sécurité JWT

Bien que JWT fournisse des bases solides pour la sécurité des API, une implémentation correcte est essentielle.

Gardez les jetons à courte durée de vie

Définissez la revendication exp (expiration) sur une courte durée — 15 minutes à 1 heure pour les jetons d'accès. Utilisez des jetons d'actualisation (refresh tokens) à durée de vie plus longue (jours ou semaines) pour obtenir de nouveaux jetons d'accès sans demander à l'utilisateur de se réauthentifier.

Utilisez toujours HTTPS

JWT ne chiffre pas son payload. Toute personne qui intercepte le jeton peut le décoder et lire son contenu. Transmettez toujours les JWT via HTTPS pour empêcher l'interception.

Validez tout

Vérifiez toujours la signature, contrôlez que le jeton n'a pas expiré, confirmez que aud (audience) correspond à votre application et rejetez les jetons dont les algorithmes sont inattendus.

Stockez les jetons de manière sécurisée

Côté client, stockez les JWT dans des cookies HTTP-only lorsque c'est possible, ou en mémoire pour les applications à page unique. Évitez localStorage pour les jetons qui donnent accès à des données sensibles.

Idées reçues courantes sur les JWT

« JWT est chiffré. » — Non. JWT est signé, pas chiffré. Le payload est encodé en base64url, ce qui est réversible. JWE (JSON Web Encryption) fournit le chiffrement, mais il s'agit d'une spécification distincte qui n'est pas couverte par le JWT standard.

« JWT empêche le CSRF. » — Pas à lui seul. Un JWT dans un header Authorization aide, mais si le jeton est dans un cookie, une protection CSRF est toujours nécessaire.

« JWT sert uniquement à l'authentification. » — JWT est utilisé pour l'authentification, mais aussi pour l'échange de données d'autorisation, les sessions sans état et le partage sécurisé d'informations entre services.

Décodez et explorez JWT en ligne

Utilisez l'outil de décodage JWT pour inspecter n'importe quel JSON Web Token. Collez votre jeton et voyez instantanément le header, le payload et l'algorithme de signature décodés. L'outil vous aide à comprendre quelles données vos jetons contiennent et à vérifier qu'ils sont correctement structurés.