- JWT est l’abréviation de JSON Web Tokens, un standard pour les jetons authentifiés.
- Un JWT se compose d’un en-tête, d’une charge utile et d’une signature ou d’un code d’authentification de message.
- Toute personne disposant de la clé de vérification peut confirmer l’authenticité de la charge utile.
Modèle d’utilisation courant des JWT
- Un JWT contient des informations comme l’émetteur, le destinataire, le sujet et la date d’expiration.
- Après avoir vérifié l’authenticité du jeton, le destinataire contrôle qu’il n’a pas expiré et considère alors le sujet comme un utilisateur authentifié.
Avantages des JWT
- Le principal avantage des JWT est que le destinataire peut vérifier l’authenticité du jeton sans se connecter à la base de données des utilisateurs.
- Dans les déploiements à grande échelle, le service d’authentification peut être le seul à accéder à la base de données centrale des utilisateurs.
Problèmes de déconnexion et d’invalidation de session
- La durée de vie d’un jeton d’authentification doit être courte. Par exemple, au maximum 5 minutes.
- Le client reçoit aussi un refresh token lui permettant de demander un nouveau jeton d’authentification.
- Le refresh token joue en pratique le rôle de véritable jeton de session.
Cas où les JWT ne sont pas nécessaires
- Pour implémenter la déconnexion, il faut maintenir une liste blanche des JWT valides ou une liste noire des JWT révoqués.
- Pour bloquer un utilisateur, il faut vérifier dans la base de données l’indicateur « utilisateur actif ».
- Des relations supplémentaires sont nécessaires entre l’objet utilisateur et d’autres objets.
- Des opérations liées à la base de données sont effectuées.
Conclusion
- Si l’une de ces conditions s’applique, les JWT ne sont pas nécessaires.
- Il vaut mieux utiliser un jeton de session opaque classique et le stocker en base de données.
- Cela permet d’éviter les inconvénients des JWT et de réduire la complexité.
L’avis de GN⁺
- Les JWT conviennent aux services à grande échelle, mais peuvent introduire une complexité excessive pour la plupart des petits services.
- Un mécanisme classique de gestion de session suffit pour la majorité des applications web.
- L’utilisation des JWT peut compliquer l’implémentation de fonctionnalités comme la déconnexion et l’invalidation de session.
- Pour tirer parti des avantages des JWT, il faut examiner attentivement l’échelle du service et ses exigences.
- Comme autre option, on peut envisager un framework d’authentification comme OAuth2.
8 commentaires
Quand l’authentification de divers clients est nécessaire, l’utilisation de JWT m’a souvent apporté de nombreux avantages.
Cela dit, comme l’évolutivité et la sécurité vont toujours dans des directions différentes, si la sécurité est particulièrement importante, je pense qu’il vaut mieux utiliser une autre méthode.
Personnellement, je pense que les jetons JWT servent surtout à échanger entre systèmes, via le navigateur, des données temporaires dont la divulgation n’est pas vraiment problématique.
Pour les jetons d’authentification qui contiennent des données personnelles, il vaut mieux utiliser des jetons opaques.
D’après mon expérience personnelle, il y avait des avantages à utiliser JWT lorsqu’on construit un MVP.
Par exemple, pour un service qu’on conçoit et maintient seul, cela permet de réduire le coût de conception face aux demandes soudaines. Comme les relations de données définies au départ changent souvent complètement un ou deux mois plus tard, lorsque la conception n’est pas encore clairement fixée, j’ai le souvenir que, du moins pour tout ce qui touche à l’auth, le fait de structurer le payload JWT avec des champs optionnels et d’implémenter les fonctionnalités de cette manière permettait de faire un test marché après avoir simplement séparé les domaines dans un service monolithique, sans que l’équipe produit ait à travailler tout de suite sur la séparation des domaines et des services. (Ensuite, on pouvait suivre le processus de séparation du service plus tard. Ou bien supprimer tout ça.)
Cela dit, j’imagine que cela dépend aussi du domaine du service que l’on veut créer. Dans ce projet, comme il s’agissait d’un service temps réel avec une forte dépendance à des tiers, je me souviens avoir avancé en pensant que, si on développait trop vite, une énorme quantité de documents/lignes risquait de s’accumuler dans la base de données, ce qui ferait grimper les coûts de gestion.
Bien sûr, si l’objectif est surtout de construire rapidement, je pense qu’une approche par session est meilleure. (Au début, le couplage entre les différents services est moins fort, donc il est plus facile de tout refaire proprement si besoin.) Et le coût de transmission quand d’autres membres de l’équipe rejoignent le projet est aussi plus faible.
À l’époque, j’y ai réfléchi un moment sous plusieurs angles, mais en y repensant maintenant, j’ai l’impression que, quelle que soit l’implémentation choisie, l’impact sur le projet n’aurait sans doute pas été si important.
Personnellement, je pense qu’on tire des bénéfices à implémenter l’auth avec des JWT lorsqu’on utilise un API gateway, mais je me demande quels sont les avantages des JWT pour un service de petite taille. Parlez-vous de cas où les informations utilisateur contenues dans le JWT changent fréquemment ?
Dans les grandes lignes, c’est globalement la même chose que ce que vous avez dit. Simplement, plutôt que de devoir modifier fréquemment les informations en raison d’un changement de modélisation de l’utilisateur lui-même, on était davantage dans des cas où l’on ajoutait ces informations de façon optionnelle lorsqu’une nouvelle fonctionnalité ou un nouveau service nécessitant l’usage d’un outil tiers demandait des données complémentaires. (Pour aller un peu plus loin, on était dans une situation ambiguë quant au fait de séparer ou non l’unité de gestion de l’auth via quelque chose comme un API gateway, ou d’avoir un serveur jouant un rôle équivalent...)
Pour donner un exemple un peu plus concret, nous étions dans une situation où le service A était le service principal. Comme c’était encore un MVP, nous ne conservions dans la table utilisateur que les informations de paiement et le fait qu’un utilisateur soit vérifié ou non. Mais une demande est arrivée pour ajouter les services B et C, qui ne pouvaient être utilisés que si chaque utilisateur disposait d’informations d’authentification différentes. En plus de cela, il n’était même pas encore décidé si B serait intégré au sein du service A, et C pouvait tout aussi bien disparaître, donc l’idée était de le tester rapidement. (Et il aurait sans doute fallu ajouter la gestion des plans sans même avoir besoin de le préciser). À cela s’ajoutait la volonté de commencer par proposer B et C directement sur les pages du service web qui fournissaient déjà le service A. Compte tenu des caractéristiques du service en exploitation, tant qu’on n’avait pas créé une table de gestion des plans (ou une table générique liée à l’authentification) puis défini et mappé les relations de domaine pour chaque service, il était inévitable de devoir interroger plusieurs tables (ou collections). Dans une situation où il y aurait eu quelqu’un pour remettre de l’ordre dans le projet, j’aurais aimé qu’on fasse quelques réunions pour bien cerner le problème exact à résoudre et identifier précisément les fonctionnalités souhaitées, mais ce n’était pas garanti. Et il n’était pas non plus clair de savoir quand on pourrait résorber ce type de dette. Donc ce genre de situation semblait déjà se profiler avant même le lancement du service A... En réfléchissant à la configuration initiale, on s’est dit qu’il fallait aller vers une solution qui minimise au maximum le coût des lectures lors de l’auth et les coûts de maintenance futurs, et c’est pour cela qu’on a choisi JWT. Et au-delà de ça, j’ai l’impression qu’il y a eu énormément d’autres petits cas similaires.
Mais comme je l’ai mentionné à la fin de mon commentaire, en réalité, quelle que soit l’implémentation choisie, cela n’aurait probablement pas eu un impact énorme sur le projet lui-même. Si cela avait été implémenté avec des sessions, on aurait sans doute trouvé une solution adaptée aux sessions. En revanche, le fait que les développeurs aient continuellement été exposés à des situations où ils devaient faire le travail d’autres fonctions, ou à des contextes où le coût de communication explosait, a probablement été bien plus critique.
Même si elle convient à une architecture monolithique, lorsque l’on commence à détacher certains services ou que l’on se trouve à un tournant en matière d’extension, JWT et la logique fondée sur les sessions montrent clairement leurs différences. Il ne s’agit pas seulement de la procédure d’authentification : dans la facilité d’usage de la logique interne aussi, les méthodes pour traiter la source des données seront différentes. Je ne sais pas bien selon quels critères juger qu’un contexte de « petit service » est approprié. Est-ce qu’on part du principe que tous les services seront forcément petits ? Ou qu’un grand service sera difficile à gérer ? Je ne sais pas. Mais j’ai le sentiment que les services que nous créons devraient au minimum disposer d’une structure capable de soutenir des contextes potentiellement utiles, même si l’on ne sait pas encore dans quelle situation ils serviront. Le postulat du petit service donne simplement l’impression qu’il ne fera que rester petit.
Avis Hacker News
Résumé des commentaires de Hacker News