Comprendre le JWT : le guide complet de l'authentification moderne

Le jeton JWT est l'une des méthodes d'autorisation les plus populaires dans les applications web modernes. Utilisé dans les API, les applications mobiles et les services à architecture microservices, il permet d'éviter le stockage des sessions côté serveur.

Alors qu'auparavant, le serveur devait mémoriser chaque utilisateur via des sessions, avec JWT tout fonctionne différemment : toutes les informations sont transmises avec chaque requête. Ce système est plus rapide, plus simple à mettre à l'échelle et mieux adapté aux services distribués.

Dans cet article, nous allons découvrir ce qu'est un jeton JWT, comment il fonctionne, sa structure et ses différences avec les sessions classiques.

Qu'est-ce qu'un jeton JWT ? Explications simples

Un jeton JWT est une chaîne de caractères spéciale qui contient des informations sur l'utilisateur et permet de l'identifier sans devoir stocker de données côté serveur. JWT signifie JSON Web Token.

En d'autres termes, il s'agit d'un "passeport numérique" obtenu après connexion. Au lieu de vérifier l'utilisateur à chaque fois via la base de données, le serveur lit ce jeton et sait immédiatement qui vous êtes et ce que vous pouvez faire.

Le JWT est largement utilisé dans les applications web et mobiles, ainsi que dans les API. Par exemple :

• lors de la connexion à un site
• lors de l'authentification via une application
• lors de l'utilisation d'une API REST

L'idée principale du JWT : toutes les informations sont stockées dans le jeton lui-même, pas sur le serveur. Cela rend le système plus rapide et plus facile à mettre à l'échelle.

Le jeton ressemble généralement à une longue chaîne séparée par des points, par exemple :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Même s'il ressemble à une suite de caractères aléatoires, il contient en réalité :

• des informations sur l'utilisateur (ID, rôle)
• une date d'expiration
• une signature protégeant les données contre la falsification

Important : JWT ne chiffre pas les données, il les encode seulement. Cela signifie que le contenu peut être décodé mais qu'il ne peut pas être modifié sans invalider la signature.

Le succès du JWT vient du fait qu'il permet l'autorisation sans session. Le serveur n'a pas besoin de stocker l'état utilisateur : toutes les données sont déjà dans le jeton.

Comment fonctionne un jeton JWT ?

Le fonctionnement du JWT repose sur une idée simple : le serveur délivre un jeton une fois, puis se contente de le vérifier à chaque requête, sans mémoriser l'état de l'utilisateur.

Étapes du processus

1. L'utilisateur saisit son identifiant et son mot de passe. Ces informations sont envoyées au serveur, qui les vérifie, par exemple via la base de données.
2. Si les informations sont correctes, le serveur crée un jeton JWT contenant :
   • l'ID de l'utilisateur
   • le rôle (ex : user ou admin)
   • la date d'expiration
3. Le jeton est envoyé au client : navigateur ou application mobile.
4. Le stockage du jeton côté client peut se faire :
   • dans le localStorage
   • dans le sessionStorage
   • dans un cookie (souvent HttpOnly pour plus de sécurité)
5. À chaque requête ultérieure, le jeton est envoyé au serveur, généralement dans l'en-tête :
   Authorization: Bearer <jeton>
6. Le serveur :
   1. extrait le jeton
   2. vérifie la signature
   3. vérifie la date d'expiration
   4. extrait les données du payload
   Si tout est valide, l'utilisateur est authentifié et la requête est exécutée.

À retenir : le serveur ne conserve aucune information sur l'utilisateur entre les requêtes. Tout ce dont il a besoin est déjà dans le jeton. C'est pourquoi le JWT est qualifié de stateless (sans état).

Ce mécanisme est particulièrement pratique pour :

• les API
• les microservices
• les systèmes distribués

Le JWT est souvent utilisé en association avec OAuth : découvrez les détails dans l'article Comment fonctionne OAuth 2.0 : connexion sans mot de passe et sécurité de vos données.

Structure d'un jeton JWT

Un jeton JWT est constitué de trois parties séparées par des points : header.payload.signature

Chacune de ces parties est encodée en Base64, ce qui donne l'aspect d'une chaîne illisible mais qui possède une structure lisible à l'intérieur.

1. Header (en-tête)

Contient des informations sur le type de jeton et l'algorithme de signature.

{
  "alg": "HS256",
  "typ": "JWT"
}

• alg : l'algorithme de signature (ex : HMAC SHA-256)
• typ : le type de jeton

2. Payload (données)

Partie principale du jeton, elle stocke les informations utiles.

{
  "userId": 123,
  "role": "admin",
  "exp": 1712345678
}

On y retrouve :

• les données utilisateur
• les droits d'accès
• la date d'expiration (exp)
• la date de création (iat)

Attention : le payload n'est pas chiffré, il est simplement encodé. N'importe qui peut donc le lire.

3. Signature

La partie la plus importante, elle protège le jeton contre la falsification.

La signature est générée à partir :

• de l'en-tête
• du payload
• d'une clé secrète (côté serveur)

Si quelqu'un tente de modifier les données du jeton, la signature ne correspondra plus et le serveur rejettera la requête.

En résumé, un JWT est bien plus qu'une simple chaîne : c'est un conteneur autonome contenant à la fois les données et leur protection. Le serveur n'a pas besoin d'interroger la base de données pour savoir qui se connecte : tout est déjà dans le jeton.

JWT : autorisation et authentification, quelle différence ?

Dans l'utilisation du JWT, deux notions sont souvent confondues : authentification et autorisation. Elles sont liées, mais distinctes.

Authentification

C'est le processus de vérification de l'identité de l'utilisateur. La question à laquelle répond le système : qui es-tu ?

Exemple :

• l'utilisateur saisit ses identifiants
• le serveur vérifie les données
• si tout est correct, l'utilisateur est authentifié

C'est à ce stade que le jeton JWT est généralement créé.

Autorisation

Il s'agit de l'étape suivante : qu'as-tu le droit de faire ?

Par exemple :

• l'utilisateur ordinaire peut lire des données
• l'administrateur peut les modifier

Ces informations sont généralement stockées dans le payload du JWT (souvent dans le champ role).

Comment le JWT intervient-il dans ces processus ?

1. L'utilisateur s'authentifie (connexion)
2. Le serveur délivre un jeton JWT
3. Le jeton contient déjà les droits d'accès
4. À chaque requête, le serveur autorise ou non, en lisant les données du jeton

Autrement dit, le JWT réunit les deux processus :

• il confirme l'identité
• il stocke les droits d'accès

À noter : le JWT ne réalise pas l'authentification lui-même, il ne fait que stocker le résultat de la vérification utilisateur.

JWT vs sessions : quelles différences ?

Pour comprendre l'intérêt du JWT, il est utile de le comparer à l'approche traditionnelle des sessions.

Fonctionnement des sessions

Après la connexion de l'utilisateur, le serveur :

• crée un enregistrement en mémoire ou en base de données
• attribue un session ID
• envoie cet ID via un cookie

À chaque requête :

• le navigateur envoie le session ID
• le serveur cherche les données associées
• il sait qui est l'utilisateur

Le serveur conserve donc l'état utilisateur.

Fonctionnement du JWT

Au lieu de conserver des données côté serveur :

• le serveur crée un jeton avec les informations
• l'envoie au client
• le client stocke le jeton
• à chaque requête, il renvoie le jeton

Le serveur ne cherche rien en base : il vérifie simplement le jeton.

Différences clés

1. Stockage des données
   • Sessions : sur le serveur
   • JWT : dans le jeton
2. Scalabilité
   • Sessions : plus complexe (stockage partagé nécessaire)
   • JWT : plus simple (les serveurs sont indépendants)
3. Performance
   • Sessions : accès à la base ou la mémoire à chaque requête
   • JWT : vérification de la signature sans requête externe
4. Sécurité
   • Sessions : révocation facile côté serveur
   • JWT : plus difficile à révoquer (une fois émis)

Quand privilégier le JWT ?

• API et microservices
• Applications mobiles
• Systèmes distribués
• Autorisation via des services tiers

Quand privilégier les sessions ?

• Sites simples
• Rendu côté serveur (SSR)
• Lorsque la gestion stricte des sessions est nécessaire
• Lorsque la révocation rapide de l'accès est importante

En résumé : le JWT offre flexibilité et scalabilité, tandis que les sessions privilégient le contrôle et la simplicité de gestion.

Access Token et Refresh Token : comment fonctionne le duo ?

Dans la pratique, le JWT n'est presque jamais utilisé seul. On l'associe à un access token et un refresh token pour allier sécurité et confort.

Access Token

Le jeton d'accès est le jeton principal utilisé lors des requêtes. Caractéristiques :

• courte durée de vie (5 à 30 minutes)
• envoyé à chaque requête
• contient les données utilisateur

En cas de vol, l'agresseur n'aura accès que pour une période limitée.

Refresh Token

Le refresh token est un jeton secondaire servant à régénérer l'access token. Caractéristiques :

• durée de vie plus longue (jours ou semaines)
• non utilisé dans les requêtes courantes
• stocké de façon plus sécurisée (souvent dans un cookie HttpOnly)

Comment cela fonctionne-t-il ensemble ?

1. L'utilisateur se connecte
2. Le serveur délivre :
   • un access token
   • un refresh token
3. L'utilisateur effectue ses requêtes avec l'access token
4. Lorsque l'access token expire :
   • le client envoie le refresh token au serveur
   • le serveur le vérifie
   • émet un nouvel access token
5. L'utilisateur continue sans devoir se reconnecter

Pourquoi ne pas utiliser un seul JWT ?

• Un jeton longue durée est pratique, mais dangereux en cas de fuite
• Un jeton court est plus sûr, mais risque de déconnecter trop souvent

Le combo access + refresh résout ce problème : sécurité et confort réunis.

Point sécurité :

• Le refresh token est souvent stocké dans un cookie HttpOnly
• Non accessible en JavaScript
• Protégé contre les attaques XSS

Cette approche est la norme dans la plupart des systèmes d'authentification modernes.

Sécurité des jetons JWT

Le JWT est considéré comme sécurisé, à condition d'être bien implémenté. Des erreurs courantes peuvent conduire à de sérieuses failles.

Pourquoi un JWT ne peut-il pas être falsifié ?

La principale protection du JWT est sa signature.

• Le serveur signe le jeton avec une clé secrète inconnue du client
• À chaque requête, le serveur recalcule la signature et la compare

Si les données du jeton sont modifiées, la signature ne correspond plus et l'accès est refusé.

Principal risque : le vol du jeton

• On ne peut deviner un JWT, mais on peut le voler
• Un attaquant ayant le jeton peut :
  • faire des requêtes à la place de l'utilisateur
  • accéder à ses données
• Le serveur ne peut pas distinguer l'attaquant de l'utilisateur légitime

Où stocker un JWT en toute sécurité ?

1. localStorage
   • simple à utiliser
   • vulnérable aux attaques XSS
2. sessionStorage
   • légèrement plus sécurisé
   • toujours accessible en JavaScript
3. Cookie HttpOnly (meilleure option)
   • non accessible en JavaScript
   • protégé contre le XSS
   • géré automatiquement par le navigateur

Erreurs fréquentes des débutants

1. Durée de vie trop longue du jeton - risque accru
2. Stockage de données sensibles dans le JWT :
   • mots de passe
   • données personnelles
   • informations confidentielles
3. Absence de HTTPS - fuite quasi assurée du jeton
4. Pas de mécanisme de révocation
   • Préférer une courte durée de vie
   • Utiliser le refresh token

Bilan sécurité

• Utilisez toujours HTTPS
• Gardez une durée de vie courte pour les jetons
• Associez access token et refresh token
• Minimisez les données stockées dans le JWT

Quand utiliser un JWT ?

Le JWT est un outil puissant, mais il n'est pas adapté à toutes les situations. Il est important d'identifier les cas où il apporte une réelle valeur ajoutée.

Cas d'usage recommandés

1. Applications SPA (Single Page Application)
   • Front-end et back-end séparés
   • De nombreuses requêtes API
   • Pas de sessions traditionnelles
   • Avantages : pas besoin de stocker l'état, transmission simple à chaque requête
2. Applications mobiles (iOS/Android)
   • Pas de cookies standards
   • Besoin d'un mécanisme d'authentification simple
   • Avantages : stocké sur l'appareil, envoyé à chaque requête
3. API et microservices
   • Systèmes distribués, nombreux services
   • Pas de serveur de sessions centralisé
   • Avantages : pas de stockage d'état, vérification facile sur chaque service
4. Autorisation via des services tiers
   • Connexion via Google, réseaux sociaux...
   • Le JWT fonctionne très bien avec OAuth : plus de détails ici.

Quand éviter le JWT ?

1. Sites simples
   • Petit projet
   • Rendu côté serveur (SSR)
   • Sessions plus simples et plus sûres
2. Révocation rapide de l'accès
   • Impossible d'invalider facilement un JWT
   • Sessions recommandées si besoin de contrôle immédiat
3. Exigences de sécurité élevées
   • Bancaire, services d'entreprise
   • Besoin d'un contrôle total sur chaque session
   • Le JWT peut manquer de flexibilité

À retenir

Le JWT est conçu pour les architectures :

• scalables
• API et applications front-end
• systèmes distribués

Mais il n'est pas une solution universelle.

Conclusion

Le jeton JWT est une méthode d'autorisation moderne qui permet de se passer du stockage de sessions côté serveur. Il contient toutes les informations nécessaires et la signature garantit son intégrité, ce qui rend le système à la fois rapide et évolutif.

Nous avons vu :

• ce qu'est un jeton JWT et sa structure
• comment fonctionne l'autorisation sans session
• les différences avec les sessions classiques
• le rôle des access et refresh tokens
• les risques à éviter

En pratique, le JWT est idéal pour les API, les applications mobiles et les microservices, mais peut s'avérer excessif pour les projets simples.

Pour résumer : le JWT rime avec commodité et évolutivité, les sessions avec contrôle et simplicité. Le choix dépend de vos objectifs, de votre architecture et de vos exigences de sécurité.