Comment fonctionne l'authentification JWT : jetons sans sessions
Fonctionnement de l'authentification JWT, affiché sur un canevas interactif : informations d'identification, jeton signé en trois parties et manière dont chaque demande est vérifiée sans état.
Un jeton Web JSON est une déclaration signée et autonome indiquant qui vous êtes : le serveur le crée une fois lors de la connexion, et chaque requête ultérieure fait ses preuves avec le jeton au lieu d'une recherche de session.
Comment fonctionne l'authentification JWT : jetons sans sessions
Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire ce visuel
- Lire de gauche à droite : connexion, problème de jeton, demandes authentifiées.
- La ligne de l'utilisateur et celle du serveur alternent, donc chaque flèche représente soit l'utilisateur fournissant quelque chose, soit le serveur décidant de quelque chose.
- Les deux formes de rejet en haut des colonnes de connexion et de demande sont les points finaux d'échec : chaque décision sur le canevas alimente l'une d'entre elles.
Prouver qui vous êtes
"L'utilisateur soumet son e-mail et son mot de passe" et "Le serveur vérifie les informations d'identification par rapport à la base de données" sont les seuls endroits où un mot de passe existe dans le flux. « Credentials valides ? » se divise en chemin heureux et « Connexion rejetée ». Il s'agit d'une authentification conventionnelle : la partie JWT démarre une fois la vérification des informations d'identification réussie.
Frapper le jeton
"Le serveur construit l'en-tête, la charge utile et la signature" est le cœur du visuel. L'en-tête nomme l'algorithme de signature ; la charge utile contient les revendications : l'identifiant utilisateur, l'expiration et toutes les étendues ; la signature les lie afin que le jeton ne puisse pas être modifié sans détection. "Le serveur signe le token avec sa clé secrète" est l'acte qui le rend digne de confiance : seul un serveur détenant le secret peut produire une signature valide. "Le client reçoit le JWT et le stocke" remet l'artefact au client, où il réside jusqu'à son expiration.
Vérification apatride
"Le client envoie le JWT dans l'en-tête d'autorisation" commence la partie répétée du flux, et "Le serveur vérifie la signature avec sa clé secrète" est la raison pour laquelle cela évolue : la revérification d'une signature est un calcul, pas une recherche dans la base de données, il n'y a donc pas de magasin de session central à consulter. « Signature valide et non expirée ? » ajoute le contrôle de temps, le routage des jetons invalides ou expirés à "Demande rejetée avec 401" et les jetons valides à "Le serveur fait confiance aux réclamations et traite la demande".
Relations et enseignements clés
- Un JWT est composé de trois parties (en-tête, charge utile, signature) reliées par des points ; la charge utile est lisible mais inviolable.
- La signature transforme l'identité en capacité : la possession d'un jeton valide et non expiré est ce qui authentifie la demande.
- La vérification est sans état : le recalcul de la signature remplace la recherche de session.
- Le jeton doit être stocké en toute sécurité par le client et envoyé à chaque demande, son expiration constitue donc la véritable limite de sécurité.
- Les JWT et OAuth vont de pair : OAuth décide de ce que le client peut faire, et JWT est un format commun pour le jeton qui le transporte.
Quand utiliser ce visuel
- Enseigner à une nouvelle équipe backend pourquoi aucune table de session n'est nécessaire et ce que prouve réellement la signature.
- Choisir entre JWT et les sessions côté serveur pour un service où la mise à l'échelle horizontale rend l'état partagé pénible.
- Examiner les revendications d'un jeton (expiration, émetteur, audience) avant de lui faire confiance dans un microservice.
Comment cela fonctionne
Répertoriez les revendications que vos jetons portent réellement
À l'étape « en-tête, charge utile et signature », ajoutez les revendications réelles que vous émettez (sub, exp, iss, aud, toutes les portées) afin que le diagramme documente votre contrat de jeton.
Ajouter le flux d'actualisation
Insérez le chemin du jeton d'actualisation après expiration : le client présente un jeton d'actualisation de longue durée, le serveur crée un nouveau jeton d'accès et la session se poursuit sans nouvelle connexion.
Nommez votre stratégie de clé de signature
Annotez l'étape de signature avec votre gestion de clés : un seul secret partagé (HS256) ou une paire de clés publique/privée (RS256), puisque ce choix décide qui peut vérifier le token.
Ajouter les branches d'échec
Incluez les jetons expirés, mal formés et falsifiés comme points de terminaison explicites afin que le diagramme couvre les rejets réellement renvoyés par votre API.
Questions fréquentes
Qu'est-ce qu'un JWT et que contient-il ?
Un jeton Web JSON est une chaîne de trois parties séparées par des points : un en-tête indiquant l'algorithme de signature, une charge utile de réclamations sur l'utilisateur et la durée de vie du jeton, et une signature. L'en-tête et la charge utile sont en JSON codé en base64 (lisible par tous) et la signature est ce qui empêche leur modification sans la clé de signature.
Pourquoi l'authentification JWT est-elle appelée apatride ?
Parce que le serveur ne stocke rien sur la session. Chaque requête arrive avec le token, et le serveur vérifie sur place la signature et l'expiration. Il n'y a pas de table de session à interroger ni d'état à répliquer sur les serveurs, ce qui permet à l'approche d'évoluer horizontalement. Le coût est qu’un jeton ne peut pas être révoqué avant son expiration sans machinerie supplémentaire.
Un JWT est-il sécurisé si quelqu'un peut lire la charge utile ?
Lire et faire confiance sont des choses différentes. La charge utile n'est pas cryptée (n'y mettez pas de secrets) mais la signature signifie que toute modification invalide le jeton, donc un client ne peut pas modifier ses propres revendications. Pour la sécurité du transport, le jeton voyage à l'intérieur de HTTPS et les données auxquelles il accorde l'accès sont protégées par le serveur de ressources qui applique les revendications.
Quel est le lien entre JWT et OAuth ?
Ils résolvent différentes moitiés du problème. OAuth est le protocole d'autorisation : comment un client obtient une autorisation et un jeton. JWT est un format de jeton. En pratique, les jetons d'accès OAuth sont souvent des JWT : le serveur d'autorisation signe un JWT portant les scopes, et les serveurs de ressources le vérifient. Ce canevas couvre la moitié de l’authentification ; le visuel OAuth couvre la moitié de la délégation.
Modifier ce visuel dans QueryChart (FlowJam)
Ouvrez ce canevas JWT exact en tant que votre propre graphique, renommez le client et le serveur en vos services et annotez vos propres revendications.