Qu'est-ce qu'un JWT ? Comprendre les jetons Web JSON et l'authentification sans état

Lorsque vous vous connectez à une application moderne à page unique (comme React ou Vue) ou à une application mobile, le serveur a besoin d'un moyen de se souvenir de qui vous êtes. Traditionnellement, il le faisait en stockant un « ID de session » dans une énorme base de données sur le serveur et en déposant un cookie sur votre navigateur. Chaque fois que vous cliquiez sur un bouton, le serveur devait rechercher cet identifiant dans sa base de données. C'est ce qu'on appelle l'authentification avec état.

Cependant, à l’ère des microservices et de la mise à l’échelle du cloud, les bases de données sont devenues un goulot d’étranglement. Pour résoudre ce problème, les développeurs ont adopté l'authentification sans état via des jetons Web JSON (JWT). Avec JWT, le serveur n'a pas besoin de se souvenir de qui vous êtes : votre navigateur indique exactement au serveur qui vous êtes et utilise la cryptographie pour le prouver.

L'anatomie d'un JWT

Si vous inspectez le trafic réseau après vous être connecté à une application moderne, vous verrez probablement un en-tête « Autorisation : porteur » suivi d'une longue chaîne de caractères d'apparence aléatoire séparée par deux points. C'est un JWT.

Un JWT se compose exactement de trois parties : Header.Payload.Signature.

1. L'en-tête

La première partie est un objet JSON codé en Base64URL qui décrit simplement le jeton. Il contient généralement deux propriétés : le type de jeton (JWT) et l'algorithme de signature utilisé (tel que HMAC SHA256 ou RSA).

2. La charge utile (réclamations)

La partie centrale est également un objet JSON codé en Base64URL. C’est là que se trouvent les données réelles. Ces éléments de données sont appelés « réclamations ». Par exemple, il peut contenir votre ID utilisateur, votre rôle (par exemple « Administrateur ») et un horodatage d'expiration. Étant donné que cette charge utile est attachée à chaque requête, le serveur sait instantanément qui vous êtes sans interroger une base de données.

AVERTISSEMENT CRITIQUE : La charge utile est simplement codée, non chiffrée. Quiconque intercepte un JWT peut facilement le décoder et lire la charge utile. Ne stockez jamais de mots de passe, de numéros de sécurité sociale ou de données sensibles dans une charge utile JWT.

3. La signature

Si n’importe qui peut lire et modifier la charge utile, qu’est-ce qui empêche un utilisateur malveillant de changer son rôle de « Utilisateur » à « Administrateur » ? La réponse est la Signature.

Pour créer la signature, le serveur prend l'en-tête, la charge utile et une clé secrète hautement sécurisée (connue uniquement du serveur) et les exécute via un algorithme cryptographique (comme SHA256). Le hachage résultant devient la Signature.

Lorsque le serveur reçoit un jeton du client, il recalcule la signature à l'aide de sa clé secrète. Si l'utilisateur a falsifié la charge utile (même en modifiant une seule lettre), la signature recalculée ne correspondra pas à la signature du jeton et le serveur rejettera instantanément la demande comme frauduleuse.

Pourquoi les microservices aiment les JWT

Imaginez une entreprise comme Netflix. Ils disposent d'un serveur d'authentification, d'un serveur de streaming vidéo et d'un serveur de facturation. S'ils utilisaient des sessions traditionnelles, chaque serveur devrait communiquer en permanence avec une base de données centrale pour vérifier si un utilisateur est connecté.

Avec les JWT, le serveur d'authentification signe le jeton à l'aide d'une clé privée. L'utilisateur transmet ensuite ce jeton directement au serveur vidéo. Étant donné que le serveur vidéo possède la clé publique, il peut vérifier la signature de manière indépendante. Le serveur vidéo sait exactement qui est l'utilisateur sans jamais parler au serveur d'authentification ou à une base de données. Cela permet à l’infrastructure d’évoluer à l’infini sans goulots d’étranglement.

Le côté obscur : invalidation du jeton

Les JWT ne sont pas parfaits. Leur plus grande force (être apatride) est aussi leur plus grande faiblesse. Étant donné que le serveur ne conserve pas d'enregistrement des jetons actifs, vous ne pouvez pas facilement déconnecter un utilisateur ou invalider un jeton spécifique avant son expiration.

Si un pirate informatique vole le JWT d'un utilisateur, il dispose d'un accès complet jusqu'à ce que l'horodatage d'expiration du jeton soit épuisé. Pour atténuer ce risque, les ingénieurs en sécurité utilisent un système à deux jetons :

• Jetons d'accès : JWT de courte durée (par exemple, 15 minutes) utilisés pour les requêtes API.
• Actualiser les jetons : jetons avec état de longue durée stockés en toute sécurité, utilisés uniquement pour demander de nouveaux jetons d'accès. Si un compte est compromis, le serveur révoque le jeton d'actualisation et le jeton d'accès du pirate informatique mourra naturellement dans 15 minutes.

Foire aux questions (FAQ)