Quel est l'avantage d'utiliser les JWT par rapport aux sessions dans des situations telles que l'authentification?
Est-il utilisé comme une approche autonome ou est-il utilisé dans la session?
122
JWT n'a aucun avantage par rapport à l'utilisation de "sessions" en soi. Les JWT fournissent un moyen de maintenir l'état de session sur le client au lieu de le faire sur le serveur.
Ce que les gens veulent souvent dire en posant cette question est "Quels sont les avantages de l'utilisation des JWT par rapport à l'utilisation des sessions côté serveur "
Avec les sessions côté serveur, vous devrez soit stocker l'identifiant de session dans une base de données, soit le conserver en mémoire et vous assurer que le client atteint toujours le même serveur. Les deux ont des inconvénients. Dans le cas de la base de données (ou d'un autre stockage centralisé), cela devient un goulot d'étranglement et une chose à maintenir - essentiellement une requête supplémentaire à effectuer avec chaque demande.
Avec une solution en mémoire, vous limitez votre mise à l'échelle horizontale, et les sessions seront affectées par des problèmes de réseau (clients itinérants entre Wifi et données mobiles, redémarrage des serveurs, etc.)
Déplacer la session vers le client signifie que vous supprimez la dépendance sur une session côté serveur, mais cela impose son propre ensemble de défis.
Ces problèmes sont partagés par les JWT et d'autres mécanismes de session côté client.
JWT en particulier aborde le dernier d'entre eux. Il peut être utile de comprendre ce qu'est un JWT:
C'est un peu d'information. Pour les sessions utilisateur, vous pouvez inclure le nom d'utilisateur et l'heure à laquelle le jeton expire. Mais cela pourrait être n'importe quoi, même l'ID de session ou le profil complet de l'utilisateur. (Veuillez ne pas le faire cependant) Il a une signature sécurisée qui empêche les parties malveillantes de générer de faux jetons (vous devez accéder à la clé privée du serveur pour les signer et vous pouvez vérifier qu'ils n'ont pas été modifiés après leur signature) envoyez-les avec chaque demande, tout comme un cookie ou un en- Authorizationtête serait envoyé. En fait, ils sont généralement envoyés dans l'en- Authorizationtête HTTP, mais l'utilisation d'un cookie convient également.
Le jeton est signé et le serveur peut donc vérifier son origine. Nous supposerons que le serveur fait confiance à sa propre capacité à signer en toute sécurité (vous devez utiliser une bibliothèque standard: n'essayez pas de le faire vous-même et sécurisez le serveur correctement)
En ce qui concerne le transport sécurisé du jeton, la réponse est généralement de l'envoyer via un canal crypté, généralement httpS.
En ce qui concerne le stockage sécurisé du jeton dans le client, vous devez vous assurer que les méchants ne peuvent pas y accéder. Cela (principalement) signifie empêcher JS des mauvais sites Web de lire le jeton pour le leur renvoyer. Ceci est atténué en utilisant les mêmes stratégies que celles utilisées pour atténuer d'autres types d'attaques XSS.
Si vous avez besoin d'invalider les JWT, il existe certainement des moyens d'y parvenir. Stocker une époque par utilisateur uniquement pour les utilisateurs qui ont demandé que leurs «autres sessions se terminent» est une méthode très efficace qui sera probablement suffisante. Si une application nécessite une invalidation par session, alors un ID de session peut être conservé de la même manière et la table des "jetons tués" peut toujours être maintenue pour être beaucoup plus petite que la table utilisateur complète (il vous suffit de conserver les enregistrements plus récents que le la plus longue durée de vie autorisée du jeton.) Ainsi, la possibilité d'invalider le jeton annule partiellement l'avantage des sessions côté client dans la mesure où vous auriez à maintenir cet état de session interrompue. Ce sera probablement une table beaucoup plus petite que la table d'état de session d'origine, donc les recherches sont encore plus efficaces.
Un autre avantage de l'utilisation des jetons JWT est qu'il est raisonnablement facile à implémenter en utilisant des bibliothèques disponibles dans probablement toutes les langues auxquelles vous pouvez vous attendre. Il est également complètement séparé de votre schéma d'authentification utilisateur initial - si vous passez à un système basé sur les empreintes digitales, vous n'avez pas besoin de modifier le schéma de gestion de session.
Un avantage plus subtil: étant donné que le JWT peut transporter des «informations» et que le client peut y accéder, vous pouvez maintenant commencer à faire des choses intelligentes. Par exemple, rappelez à l'utilisateur que sa session expirera quelques jours avant sa déconnexion, en lui donnant la possibilité de s'authentifier à nouveau, en fonction de la date d'expiration du jeton. Tout ce que vous pouvez imaginer.
Donc, en bref: les JWT répondent à certaines des questions et des lacunes d'autres techniques de session.
Bien que JWT ne réponde pas aux autres problèmes tels que le stockage ou le transport sécurisé, il n'introduit aucun nouveau problème de sécurité.
Il existe beaucoup de négativité autour des JWT, mais si vous implémentez la même sécurité que vous le feriez pour d'autres types d'authentification, tout ira bien.
Une dernière remarque: il ne s'agit pas non plus de cookies vs jetons. Les cookies sont un mécanisme de stockage et de transport de bits d'informations et peuvent également être utilisés pour stocker et transporter des jetons JWT.
La réponse courte est: aucune.
Une version plus longue est:
J'ai implémenté des JWT pour la gestion de session après avoir lu cette recommandation dans la documentation GraphQL :
La mise en œuvre était en effet simple car elle ne faisait qu'ajouter un peu de complexité. Après un certain temps cependant, j'ai (comme vous) commencé à me demander quels étaient les avantages. Il s'avère qu'il y en a très peu (ou peut-être aucun) pour JWT en ce qui concerne la gestion de session, comme ce billet de blog l'explique en détail:
Arrêter d'utiliser JWT pour les sessions
la source
Mes deux cents, qui sur le chemin ajoutent un peu de contraste au célèbre article de blog de joepie91.
Étant donné que les applications d' aujourd'hui (et de demain) sont (pour la plupart) natives du cloud
Il y a un avantage économique à l' authentification JWT sans état , qui évolue à mesure que l'application évolue: les
applications cloud entraînent des coûts à chaque respiration .
Ce coût est réduit lorsque les utilisateurs n'ont plus à s'authentifier «auprès» d'un magasin de sessions.
Traitement L'
exécution d'un magasin de session 24/7 coûte de l'argent.
Vous ne pouvez pas vous en sortir avec des solutions basées sur la mémoire dans le monde de K8S, car les pods sont éphémères.
Les sessions collantes ne fonctionneront pas bien pour la même raison.
Stockage Le
stockage des données coûte de l'argent. le stockage des données dans un SSD coûte encore plus cher.
Les opérations liées à la session doivent être résolues rapidement, un lecteur optique n'est donc pas une option.
E / S
Certains fournisseurs de cloud facturent de l'argent pour les E / S liées au disque.
Bande passante
Certains fournisseurs de cloud facturent l'activité réseau entre les instances de serveur.
Cela s'applique car il est presque certain que l'API et le magasin de sessions sont des instances distinctes.
Clustering du magasin de sessions
Le coût augmente encore plus tous les coûts mentionnés ci-dessus.
la source
J'avais une question similaire en choisissant entre JWT et token + cache pour l'authentification des utilisateurs.
Après avoir lu ces articles, il est clair pour moi que les avantages promis par JWT ne dépassent pas les problèmes qu'il apporte. Donc, token + cache (Redis / Memcached) est la voie à suivre pour moi.
En-têtes d'authentification vs JWT vs sessions - Comment choisir la bonne technique d'authentification pour les API
Techniques d'authentification pour les API
Arrêtez d'utiliser jwt pour les sessions
la source