JWT (JSON Web Token)

Qu'est-ce qu'un JWT ?

Un JWT, pour JSON Web Token, est un format de jeton compact et autonome défini par la RFC 7519. Il permet à deux parties d'échanger un ensemble de revendications (« claims ») : l'identité de l'utilisateur, ses droits, la date d'expiration du jeton. Ces informations sont vérifiables car le jeton est signé numériquement. Concrètement, le serveur émet un JWT après une connexion réussie, le client le conserve, puis chaque requête suivante vers l'API le transmet, ce qui permet au serveur d'identifier l'appelant sans consulter de session.

L'idée centrale est que le jeton porte lui-même ses informations. Au lieu de stocker une session en base de données, le serveur a seulement besoin de la clé secrète ou publique qui sert à contrôler la signature. C'est ce qui rend les JWT populaires pour l'authentification sans état (« stateless ») dans les applications web, les applications mobiles et les microservices.

Structure d'un JWT

Un JWT se compose de trois parties encodées en Base64URL et séparées par des points : header.payload.signature.

• En-tête (header) : le type de jeton et l'algorithme de signature, par exemple {"alg":"HS256","typ":"JWT"}.
• Charge utile (payload) : les revendications. Les champs standards sont sub (sujet), iss (émetteur), aud (destinataire) et exp (date d'expiration). Vous pouvez ajouter vos propres champs, comme un rôle ou une offre.
• Signature : un hachage de l'en-tête et de la charge utile calculé avec un secret (HMAC) ou une clé privée (RSA, ECDSA). Elle prouve que le contenu n'a pas été modifié.

Voici une charge utile décodée : {"sub":"user_42","role":"editor","exp":1767225600}. Tout le monde peut la lire, car Base64URL est un encodage et non un chiffrement. Seule la signature protège son intégrité.

Comment fonctionne l'authentification par JWT

• L'utilisateur envoie ses identifiants au point d'accès de connexion.
• Le serveur les vérifie et renvoie un JWT signé, souvent valable 5 à 15 minutes.
• Le client transmet le jeton dans l'en-tête Authorization: Bearer <token> à chaque requête.
• Le serveur contrôle la signature et la date d'expiration exp, puis traite la requête.
• Quand le jeton expire, un jeton de rafraîchissement (« refresh token »), plus durable, permet d'en obtenir un nouveau.

Le JWT sert souvent de jeton d'accès dans un flux OAuth 2.0 ou OpenID Connect, d'où la confusion fréquente entre les deux notions. OAuth est le cadre d'autorisation, tandis que le JWT est un format de jeton parmi d'autres.

JWT ou cookie de session ?

Bonnes pratiques de sécurité et pièges courants

• Ne placez jamais de donnée sensible (mot de passe, donnée personnelle) dans la charge utile, car tout le monde peut la lire.
• Utilisez des durées de vie courtes et des jetons de rafraîchissement, car un JWT volé reste valide jusqu'à son expiration.
• Vérifiez toujours la signature, refusez l'algorithme none et imposez l'algorithme attendu côté serveur.
• Préférez un cookie HttpOnly et Secure au localStorage pour limiter l'exposition aux attaques XSS.
• Conservez les clés de signature dans un gestionnaire de secrets et renouvelez-les régulièrement.

Le JWT convient quand plusieurs services doivent faire confiance à la même identité. Il convient mal quand une révocation instantanée est nécessaire : une session côté serveur ou une liste de jetons refusés est alors plus sûre.

Le JWT chez BeBranded

Sur les applications web sur mesure que nous concevons, l'authentification est pensée dès le départ : nous choisissons entre sessions et jetons d'accès JWT selon l'architecture, et nous nous appuyons sur des solutions éprouvées comme Supabase, Firebase ou Xano plutôt que de réécrire la gestion des jetons. Découvrez la manière dont notre équipe aborde les produits sécurisés sur notre page Applications web.