Comment fonctionnent les JSON Web Tokens (JWT)

Un JSON Web Token (JWT, prononcé « djot ») est une chaîne compacte et signée qui transporte quelques informations, appelées claims, d'une partie à une autre. Les serveurs les remettent après la connexion et votre application renvoie le jeton avec chaque requête pour prouver qui vous êtes, sans que le serveur garde de session. Décodez n'importe quel jeton avec le Décodeur JWT ou créez-en un avec le Générateur et Vérificateur de JWT.

Trois parties séparées par des points

Un JWT ressemble à en-tête.charge.signature. Chaque partie est du Base64 dans sa forme sûre pour les URL. Voici un vrai jeton créé avec le secret secret :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ.K5CXsF2jBQ9-Pr4xg7yeVj3Vr-Be0jvTHInQnYK-aSk

L'en-tête (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) se décode en :

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

La charge (eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFuYSIsImlhdCI6MTcwMDAwMDAwMCwiZXhwIjoxNzAwMDAzNjAwfQ) se décode en :

{"sub":"1234567890","name":"Ana","iat":1700000000,"exp":1700003600}

La signature (K5CXsF2jBQ9-Pr4xg7yeVj3Vr-Be0jvTHInQnYK-aSk) est calculée sur les deux premières parties avec l'algorithme et la clé nommés dans l'en-tête. HS256 est un HMAC avec SHA-256 : qui connaît le secret peut à la fois la créer et la vérifier.

Claims enregistrés

Les temps sont en secondes depuis 1970 (voyez le Convertisseur de Timestamp Unix) : le jeton ci-dessus a été émis à 1700000000, soit le 14 novembre 2023, et expire une heure plus tard.

Comment un serveur vérifie un jeton

1. Il découpe le jeton en trois parties et décode l'en-tête.
2. Il recalcule la signature sur en-tête.charge avec l'algorithme et la clé attendus et la compare à celle du jeton. Avec un autre secret, cela échoue : le jeton ci-dessus se vérifie avec secret et est rejeté avec tout autre.
3. Il vérifie les claims : exp n'est pas dépassé, nbf l'est, et iss et aud ont les valeurs attendues.

Algorithmes de signature

• HS256 / HS384 / HS512 utilisent un secret partagé unique. C'est simple, mais tout service qui vérifie les jetons peut aussi les falsifier.
• RS256 / ES256 utilisent une clé privée pour signer et une clé publique pour vérifier, la clé publique pouvant donc être largement partagée. Préférez-les quand de nombreux services vérifient des jetons émis par un seul.

Pièges

• Un JWT est signé, pas chiffré. N'importe qui peut lire la charge en la décodant. N'y mettez jamais de mots de passe ni de secrets.
• Fixez toujours l'algorithme côté serveur. N'acceptez que l'algorithme attendu. Faire confiance au champ alg a conduit à des attaques, comme l'en-tête {"alg": "none"} que certaines bibliothèques ont autrefois accepté comme « aucune signature requise ».
• Utilisez un exp court. Un jeton volé fonctionne jusqu'à son expiration. Utilisez des durées courtes plus des jetons de rafraîchissement.
• Un jeton ne peut pas se révoquer de lui-même. Une fois émis, il reste valide jusqu'à exp. Si vous avez besoin d'une déconnexion immédiate, tenez une liste de refus de valeurs jti ou utilisez des sessions côté serveur.
• Stockez les jetons avec soin. Les jetons dans localStorage sont lisibles par tout script de la page : une faille XSS les expose ; un cookie HttpOnly est plus difficile à voler.
• Utilisez un secret long et aléatoire pour HMAC, pas un mot comme secret. L'exemple ici n'est qu'une démonstration.

Voyez JWT et HMAC.