Avantages du jeton Web JSON (JWT) par rapport à un jeton de session de base de données
Avec un système de jeton de session de base de données, je pourrais avoir un identifiant utilisateur avec un nom d'utilisateur/mot de passe, le serveur pourrait générer un jeton (un uuid par exemple) et le stocker dans la base de données et retourner ce jeton au client. Chaque demande en découlant inclurait le jeton et le serveur vérifierait si le jeton est valide et à quel utilisateur il appartient.
En utilisant JWT, il ne serait pas nécessaire d'enregistrer quoi que ce soit dans la base de données en ce qui concerne la session/les jetons grâce à la combinaison de la clé secrète conservée sur le serveur et du jeton signé que le client conserve et envoie avec chaque demande.
C'est bien, mais en plus d'enregistrer une base de données, vérifiez chaque demande (ce qui serait rapide de toute façon car il s'agit simplement de vérifier une table de hachage), je ne vois pas clairement quels sont les avantages de l'utilisation de JWT. Pouvez-vous expliquer à quelqu'un qui est familier avec cela? Ignorons les cookies, c'est spécifiquement un jeton personnalisé de base de données comme décrit ci-dessus et JWT que j'essaie de comparer et de comprendre les avantages.
La principale différence est la taille du stockage de session et le travail de recherche requis du serveur:
Côté serveur, JWT stocke une clé unique en mémoire (ou dans un fichier de configuration) - appelée clé secrète . Cette clé a deux objectifs, elle permet de créer de nouveaux jetons chiffrés et elle fonctionne également comme une clé principale qui "ouvre tous les verrous" - ou dans la vie réelle vérifie tous les jetons. Par conséquent, le serveur répond beaucoup plus rapidement aux demandes d'authentification, car cela n'a pas d'importance si vous avez deux ou deux millions d'utilisateurs connectés - le même nombre d'enregistrements (un, cette clé de serveur) sera utilisé pour authentifier toutes les demandes des clients.
L'authentification traditionnelle qui stocke les sessions utilisateur dans une base de données, crée un enregistrement dans la base de données pour chaque utilisateur, ce qui se traduit par plusieurs clés. Donc, si vous avez deux millions d'utilisateurs connectés, le serveur créera deux millions d'enregistrements et à chaque demande du client, le serveur doit localiser l'enregistrement de session approprié dans la base de données *.
JWT laisse le soin au client de stocker et de gérer l'intégralité de l'objet session/utilisateur. En fait, cela a beaucoup plus de sens, car chaque client ne gère que ses propres données, ce qui ne cause pas non plus de charges lourdes pour le côté client.
Quant à ce que vous avez écrit dans votre dernier paragraphe, ce ne sont pas seulement les appels db que nous enregistrons ici. JWT est en fait beaucoup plus évolutif en raison de sa nature indépendante et légère, il n'échoue pas lorsque les demandes d'authentification s'accumulent et il permet au serveur de gérer l'authentification sur les appareils et services sans gérer les sessions côté serveur .
En termes de sécurité, les sessions db ont sans doute l'avantage: elles peuvent être plus sécurisées en raison de cette latence, et sont également moins vulnérables au piratage de session après l'utilisateur Se déconnecter.
* La méthode des sessions stockées db peut être optimisée avec une mise en cache efficace et en stockant uniquement l'ID de session (par opposition à l'objet utilisateur entier) dans un serveur de clé/valeur rapide tel que Redis. Cela dit, je choisirais toujours la méthode JWT sur db pour la plupart des cas.
Un jeton basé sur Json (JWT) résout les problèmes suivants:
- Problèmes mobiles: les applications mobiles natives semblent avoir des problèmes avec les cookies, donc si nous devons interroger une API distante, l'authentification de session n'est peut-être pas la meilleure solution.
- Problèmes CSRF: Si vous suivez la méthode des cookies, vous devez avoir CSRF pour éviter les demandes intersites.
Mais JWT n'utilise pas de sessions, n'a pas de problèmes avec le mobile, il n'a pas besoin de CSRF et cela fonctionne très bien avec CORS aussi. Si vous n'avez pas de jeton valide, vous ne pouvez rien faire.
Un de plus, car ce jeton est stocké dans le stockage local du client/stockage de session afin que vous puissiez également transmettre ces jetons à d'autres clients, mais vous devez partager les mêmes informations d'identification que vous avez utilisées pour générer ce JWT.