JWT vs Authentification par session

D'une manière générale, la première étape de l'utilisation d'une application est l'authentification, où l'utilisateur final fournit ses informations d'identité pour se connecter avec succès. Après cette étape, le système d'identité (c'est-à-dire le fournisseur d'identité, serveur d'authentification, etc.) sait qui est l'utilisateur et à quelles ressources il a accès.

Étant donné que le HTTP est intrinsèquement sans état, chaque requête dans une session est indépendante et ne se souvient pas des informations des précédentes. Réauthentifier les utilisateurs pour chaque action est fastidieux et nuit à l'expérience utilisateur.

Introduisons l'authentification basée sur les sessions et l'authentification JWT (JSON Web Tokens), deux méthodes populaires pour maintenir l'état d'authentification. Chacune a des avantages uniques et des compromis, et le choix entre elles dépend des besoins spécifiques de votre application. Si vous hésitez entre les deux, ce guide est là pour vous aider.

Qu'est-ce que l'authentification basée sur les sessions ?#

L'authentification basée sur les sessions repose sur le serveur pour maintenir un enregistrement de l'état d'authentification de l'utilisateur. En créant et gérant des sessions, le serveur permet aux utilisateurs de rester connectés et de continuer à interagir avec une application sans avoir à ressaisir des identifiants à chaque requête.

Comment fonctionne l'authentification basée sur les sessions ?#

Création de session

1. Un utilisateur s'authentifie et fournit des identifiants (par exemple, email et mot de passe).
2. Si les identifiants sont valides, le serveur crée un enregistrement persistant représentant cette session. La session contient des informations telles qu'une chaîne aléatoire, un identifiant utilisateur, le moment de début de la session, le moment d'expiration de la session, etc.
3. Le SessionID est stocké dans la base de données et renvoyé au client de l'utilisateur sous forme de cookie.

Validation de session

1. Le processus peut être déclenché manuellement par l'utilisateur (par exemple, en cliquant sur un onglet, en actualisant une page) ou automatiquement par le client (par exemple, lors des premiers chargements de page ou via des appels API avec un SessionID).
2. Chaque appel suivant envoie une requête HTTP du client contenant le cookie de session au serveur.
3. Le serveur valide le SessionID en consultant les données de la session stockées sur le serveur.
4. Si valide, le serveur traite la requête et autorise l'utilisateur.

Comment révoquer une session ?#

Les sessions peuvent être invalidées en temps réel, ce qui est pratique dans les situations où une révocation rapide d'accès est nécessaire.

• Déconnexion manuelle par les utilisateurs : le serveur supprime l'enregistrement de session, déconnectant ainsi l'utilisateur.
• Les administrateurs forcent la déconnexion des utilisateurs : les administrateurs ou systèmes peuvent terminer une session spécifique en la supprimant de la base de données. Par exemple, lors d'une violation de la sécurité.
• Expiration des sessions : les sessions peuvent expirer automatiquement après une durée d'inactivité définie, ou une limite de temps fixe.

Avantages de l'authentification basée sur les sessions#

• Simple et fiable : l'enregistrement de session fournit une source claire et centralisée, permettant un haut degré de confiance et rendant les décisions d'autorisation plus fiables.
• Révocation en temps réel : en supprimant ou invalidant l'enregistrement de session, l'accès d'un utilisateur peut être rapidement révoqué.

Inconvénients de l'authentification basée sur les sessions#

• Latence dans un système distribué : maintenir des données de session sur plusieurs serveurs nécessite toujours de synchroniser un magasin de sessions. Cela introduit une latence supplémentaire car le serveur doit vérifier le magasin de sessions à chaque demande.
• Consommation élevée de ressources : chaque session prend des ressources serveur, impactant les performances lorsque la base d'utilisateurs s'élargit.
• Risque de sécurité : le détournement de session (via des cookies de session volés) peut permettre un accès non autorisé aux comptes d'utilisateur.
• Utilisation limitée pour les API : l'authentification basée sur les sessions n'est pas idéale pour les applications mobiles. Elle stocke les données de session sur le serveur, ce qui peut augmenter la charge et la complexité avec de nombreux utilisateurs. De plus, elle utilise des cookies, plus difficiles à gérer sur les appareils mobiles.

Qu'est-ce que l'authentification JWT ?#

Les JSON Web Tokens (JWTs) adoptent une approche différente en intégrant toutes les informations utilisateur pertinentes directement dans un jeton, en utilisant un objet JSON. Contrairement aux méthodes basées sur les sessions, les JWTs sont sans état, ce qui signifie que le serveur ne gère pas les enregistrements d'authentification.

Comment fonctionne l'authentification JWT ?#

Un JWT se compose de trois parties : un header, un payload (charge utile) et une signature.

• Le header contient l'algorithme de signature (par exemple, HS256) et le type de jeton (JWT).
• Le payload contient les principales assertions, telles que l'identité de l'utilisateur, son rôle et le temps d'expiration.
• La signature utilise une clé pour signer le header et le payload, permettant de vérifier si la signature a été altérée.

Émission de JWT

1. Le client envoie des identifiants utilisateur au serveur d'authentification (un fournisseur d'identité universel est particulièrement bénéfique pour gérer l'accès à travers plusieurs domaines).
2. Après une authentification réussie, le serveur génère un JWT qui inclut le header, le payload et la signature.
3. AuthServer envoie le jeton émis au Client. Le client stocke le JWT (par exemple, dans les cookies, localStorage ou sessionStorage).

Les flux de travail basés sur les sessions suivent un processus similaire. Cependant, après l'authentification, l'information de l'utilisateur est stockée sur le serveur dans une session, tandis que les JWT s'appuient sur des jetons envoyés au client pour stockage et utilisation ultérieure.

Validation de jeton

1. Pour les requêtes API suivantes, le client envoie le JWT dans l'en-tête Authorization (Bearer <token>).
2. Le serveur vérifie la signature du JWT à l'aide d'une clé secrète ou publique et vérifie ses assertions (par exemple, expiration, émetteur).
3. Si le jeton est valide, le serveur accorde au client l'accès aux ressources demandées.

L'authentification basée sur les sessions nécessite que le serveur interroge un magasin de sessions, ce qui peut être lent, surtout s'il dépend de bases de données externes ou centralisées. En revanche, l'authentification JWT est sans état, avec toutes les informations nécessaires stockées dans le jeton client, et utilise la signature pour assurer la sécurité. Cela élimine le besoin de gestion des sessions, rendant le processus plus rapide et plus évolutif, en particulier dans les systèmes distribués.

Comment révoquer un JWT ?#

Du côté client, se déconnecter signifie généralement effacer la session locale et supprimer les jetons (ID, accès, jeton de rafraîchissement) du stockage. Cependant, pour l'authentification JWT, cela ne déconnecte que l'utilisateur localement, laissant la session centralisée sur le serveur d'autorisation intacte. En conséquence, les utilisateurs peuvent encore accéder à d'autres applications sous la même session jusqu'à ce que le jeton expire ou soit manuellement terminé.

Révoquer un JWT (JSON Web Token) est plus difficile que l'authentification basée sur les sessions car les JWT sont sans état et ne peuvent pas être invalidés une fois émis, à moins que des stratégies spécifiques ne soient mises en œuvre. Les méthodes courantes incluent :

• Durées d'expiration courtes : Définir une assertion exp courte (par exemple, 15 minutes) pour le JWT. Une fois expiré, l'utilisateur doit se réauthentifier. Cela minimise le risque si un jeton est compromis, car l'attaquant peut seulement l'utiliser pendant une durée limitée. Pour maintenir une expérience utilisateur fluide, un jeton de rafraîchissement peut être utilisé pour minimiser l'inconvénient de la réauthentification.
• Liste noire de jetons : Pour les cas critiques (par exemple, déconnexion de l'utilisateur, changements de mot de passe), maintenir une liste noire de jetons révoqués. Le serveur vérifie les jetons entrants par rapport à cette liste et rejette toute correspondance. Bien qu'efficace, cette approche nécessite de suivre les jetons révoqués, ce qui va à l'encontre de la nature sans état des JWT et peut devenir inefficace si la liste s'agrandit trop.
• Point de révocation : Introduire un point de révocation sur le serveur d'autorisation où les jetons (par exemple, les jetons de rafraîchissement) peuvent être invalidés. Une fois qu'un jeton de rafraîchissement est révoqué, tout jeton d'accès émis à partir de celui-ci ne sera plus renouvelé. Cette méthode fonctionne bien dans les flux OAuth2.

Avantages de l'authentification JWT#

• Rapide et plus informatif : La nature autonome des JWT rend la vérification côté client plus rapide et plus efficace, sans nécessiter d'interaction avec le serveur. Ils peuvent également inclure des assertions personnalisées (par exemple, rôles utilisateur ou autres données pertinentes) dans le jeton, permettant aux serveurs de déterminer les rôles sans interroger une base de données.
• Sécurisé amélioré : Les JWT utilisent des techniques de signature et de chiffrement, rendant les attaques plus difficiles.
• Support inter-domaine : Les JWT sont parfaits pour le Single Sign-On (SSO) et l'authentification inter-domaines. Ils permettent aux utilisateurs de s'authentifier sur plusieurs domaines ou services avec le même jeton.
• Adapté aux mobiles : Les JWT fonctionnent très bien pour les applications mobiles nécessitant une authentification sans état. Les jetons peuvent être stockés côté client et envoyés avec chaque requête, améliorant l'efficacité et la facilité d'utilisation.

Inconvénients de l'authentification JWT#

• JWT n'est pas mis à jour en temps réel

  Une fois qu'un JWT est signé, il ne peut pas être révoqué ou mis à jour, et il sera considéré valide tant que la signature est valide et n'a pas expiré.

  Si les permissions d'accès d'un utilisateur changent (généralement dégradées), l'utilisateur aura toujours un accès retiré aux ressources jusqu'à l'expiration du JWT. De même, si un JWT contient des informations d'autorisation basées sur les rôles, le nouvel objectif d'autorisation n'entrera pas en vigueur tant que l'ancien JWT n'a pas expiré. En d'autres termes, les JWT ne conviennent pas à la révocation en temps réel et les utilisateurs peuvent régler un temps d'expiration approprié pour atténuer ce problème.

• Dilemme multi-appareils et révocation

  Il n'est pas possible de valider tous les JWT émis avant qu'ils n'expirent pour mettre en œuvre la révocation de l'utilisateur de tous les appareils. Bien qu'il soit théoriquement possible de révoquer la clé de signature pour rendre le JWT invalide, cela invaliderait également tous les JWT utilisant cette clé, et le processus de traitement des clés de cache rendrait cette approche impraticable pour des opérations simples de révocation d'utilisateur.

Certains fournisseurs d'identité pourraient avoir des solutions préconstruites pour ces problèmes JWT. Pour plus d'informations, consultez "Meilleures pratiques pour améliorer l'expérience d'authentification JWT."

Quelle est la différence entre JWT et session ?#

Les sessions et les JWT sont deux approches populaires pour persister le contexte d'authentification et d'autorisation dans un monde HTTP sans état. Bien que les deux approches aient leurs avantages et inconvénients, elles offrent des bénéfices et des inconvénients différents.

Les sessions, offrent des garanties plus fortes pour l'autorisation des requêtes individuelles et sont plus simples à mettre en œuvre en toute sécurité. Cependant, leur dépendance à la validation de base de données côté serveur introduit une surcharge de latence, ce qui peut affecter négativement l'expérience utilisateur pour les applications très réactives.

Les JWT, en revanche, sont avantageux pour une autorisation plus rapide et l'interopérabilité avec les applications externes, mais nécessitent plus d'efforts de la part des développeurs pour aborder les complexités de sécurité. Par exemple, nous pouvons utiliser des webhooks pour notifier les clients lorsqu'un utilisateur redemande l'accès, afin que les clients puissent effacer le JWT mis en cache et forcer l'utilisateur à se réauthentifier.

Puisque l'authentification basée sur des jetons est plus adaptée à la montée en charge avec des inconvénients encore gérables, elle est adoptée par de plus en plus d'applications modernes.

Session vs JWT : Choisir la bonne méthode#

Votre méthode d'authentification doit correspondre à l'architecture de votre application et à ses besoins spécifiques. Voici un guide rapide pour vous aider à décider :

Quand utiliser l'authentification basée sur les sessions#

L'authentification basée sur les sessions fonctionne mieux lorsque vous avez besoin de contrôle de session en temps réel, de gestion centralisée ou que la scalabilité n'est pas un problème majeur. Voici où elle brille :

• Applications web avec sessions persistantes

  Pour des plateformes comme les sites de commerce en ligne, les sessions sont essentielles pour suivre les utilisateurs, les paniers d'achats et les préférences lors de leur visite.

• Applications nécessitant un contrôle de session en temps réel

  Les applications telles que les services bancaires ou financiers bénéficient des données de session contrôlées par le serveur, garantissant une gestion robustement sécurisée des accès.

• Systèmes mono-serveur ou de petite taille

  Les outils internes ou applications de petite taille sans besoins de scalabilité importants évoluent grâce à une gestion simplifiée des sessions pour facilité et fiabilité.

Quand utiliser l'authentification JWT#

L'authentification JWT est mieux adaptée aux applications qui priorisent la scalabilité, l'efficacité, et les systèmes distribués. Elle est particulièrement utile pour les interactions sans état entre clients et serveurs. Envisagez l'authentification basée sur des jetons pour les éléments suivants :

• Single Sign-On (SSO)

  Les JWT sont parfaits pour le Single Sign-On, permettant aux utilisateurs de s'authentifier une fois et d'accéder sans couture à plusieurs services ou applications en utilisant le même jeton. Partagez une explication détaillée sur applications sécurisées basées sur le cloud utilisant OAuth 2.0 et OIDC, avec format JWT pour à la fois les jetons d'accès et les ID tokens.

• Applications mobiles

  Les applications mobiles préfèrent souvent les JWT pour l'authentification car les jetons peuvent être stockés en toute sécurité sur l'appareil et envoyés avec chaque demande API. Explorez l'intégration rapide de l'authentification JWT pour Android / iOS.

• Architectures de microservices

  Dans les environnements de microservices, les JWT permettent à chaque service de valider indépendamment le jeton sans dépendre d'un magasin de sessions centralisé, garantissant scalabilité et efficacité.

• Authentification inter-domaine

  Les JWT excellent dans les scénarios impliquant plusieurs domaines ou sous-domaines (par exemple, api.example.com, dashboard.example.com et docs.example.com). Contrairement aux cookies, les JWT permettent l'authentification à travers les domaines sans dépendances supplémentaires.

• APIs et services web

  Les APIs RESTful et services web utilisent souvent les JWT pour l'authentification parce qu'ils sont légers, portables et éliminent le besoin de gestion de session côté serveur. En savoir plus sur l'authentification machine-à-machine pour les scénarios où votre application doit communiquer directement avec des ressources.

Meilleures pratiques pour améliorer l'expérience d'authentification JWT#

L'authentification JWT est un excellent outil, mais elle peut présenter des défis affectant l'expérience utilisateur. Logto offre une solution facile et fiable pour surmonter ces obstacles, ce qui en fait un choix de premier plan pour une authentification sécurisée et efficace.

Gestion des problèmes de déconnexion utilisateur avec JWT#

Un problème courant avec l'authentification JWT est d'assurer une expérience de déconnexion utilisateur correcte. Logto simplifie ce processus avec son SDK prêt à l'emploi.

• En effaçant les jetons et sessions locales côté client et en redirigeant les utilisateurs vers le point de fin de session de Logto, vous pouvez facilement terminer les sessions à la fois sur l'application client et le serveur.
• De plus, Logto prend en charge la déconnexion par canal secondaire, permettant au serveur d'authentification de notifier toutes les applications clientes partageant la même session lorsque l'utilisateur se déconnecte.

Cela garantit une gestion cohérente et sécurisée des sessions à travers votre écosystème. En savoir plus sur la gestion de la déconnexion.

Gestion des changements de permissions utilisateur#

Gérer les changements en temps réel des permissions utilisateur avec JWT peut aussi être compliqué. Étant donné que les JWT sont par nature sans état, n'importe quel ajouts ou modifications de permissions peuvent ne pas prendre effet avant l'expiration du jeton. Logto propose des stratégies pour gérer cela efficacement :

• Pour la réduction des permissions de cet utilisateur : Utiliser des temps d'expiration courts pour les tokens d'accès ou vérifier dynamiquement les permissions via un appel API.
• Pour l'ajout de nouvelles permissions pour cet utilisateur : Mettre à jour le serveur d'authentification pour inclure la nouvelle portée de permission et faire reconsentir les utilisateurs pour appliquer ces changements.

Ces solutions aident à garder les permissions à jour et assurent un système plus sûr et plus réactif. En savoir plus sur la gestion des changements de permissions.

Logto, une infrastructure de gestion d'accès aux identités évolutive, fournit une solution d'identité complète avec à la fois un service cloud et une version open-source disponible.