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 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 rappelle pas les informations des précédentes. Ré-authentifier les utilisateurs pour chaque action est fastidieux et nuit à l'expérience utilisateur.

Entrons dans l'authentification par session et l'authentification JWT (JSON Web Tokens), deux méthodes populaires pour maintenir l'état de l'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 par session ?#

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

Comment fonctionne l'authentification par session ?#

Création de session

1. Un utilisateur s'authentifie et fournit des informations d'identification (par exemple, e-mail et mot de passe).
2. Si les informations d'identification 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, l'identifiant de l'utilisateur, l'heure de début de la session, l'heure 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 chargements initiaux de page ou via des appels API avec un SessionID).
2. Chaque appel ultérieur envoie une requête HTTP depuis le client contenant le cookie de session au serveur.
3. Le serveur valide le SessionID en consultant les données de session stockées sur le serveur.
4. Si valable, 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 des situations où une révocation rapide de l'accès est nécessaire.

• Déconnexion manuelle des utilisateurs : Le serveur supprime l'enregistrement de session, déconnectant efficacement l'utilisateur.
• Déconnexion forcée par les administrateurs : Les administrateurs ou les systèmes peuvent terminer une session spécifique en la supprimant de la base de données. Par exemple, lors d'une faille de 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 par session#

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

Inconvénients de l'authentification par session#

• Latence dans les systèmes distribués : Maintenir les 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 fois qu'une requête est faite.
• Consommation élevée de ressources : Chaque session utilise les ressources du serveur, impactant les performances lorsque la base d'utilisateurs grandit.
• 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 utilisateur.
• Utilisation limitée pour les API : L'authentification par session 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 et une signature.

• Le header contient l'algorithme de signature (par exemple, HS256) et le type de jeton (JWT).
• Le payload contient les claims principaux, tels que l'identité de l'utilisateur, le rôle de l'utilisateur 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.

Emission de JWT

1. Le client envoie des informations d'identification utilisateur au serveur d'authentification (Un fournisseur d'identité universel est particulièrement avantageux pour gérer les 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 des cookies, localStorage ou sessionStorage).

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

Validation du jeton

1. Pour les requêtes API suivantes, le client envoie le JWT dans le header 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 claims (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 repose sur des bases de données externes ou centralisées. En revanche, l'authentification JWT est sans état, toutes les informations nécessaires étant stockées dans le jeton de client, et utilise une signature pour garantir la sécurité. Cela élimine le besoin de gestion de session, la rendant plus rapide et évolutive, surtout 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 retirer les jetons (ID, accès, actualisation) du stockage. Cependant, pour l'authentification JWT, cela ne fait que déconnecter l'utilisateur localement, laissant la session centralisée sur le serveur d'autorisation intacte. En conséquence, les utilisateurs peuvent toujours accéder à d'autres applications sous la même session jusqu'à ce que le jeton expire ou soit résilié manuellement.

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éfinissez un claim exp court (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 ne peut l'utiliser que pendant un temps limité. 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 des jetons : Pour les cas critiques (par exemple, déconnexion de l'utilisateur, changements de mot de passe), maintenez une liste noire des jetons révoqués. Le serveur vérifie les jetons entrants par rapport à cette liste de blocage 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 devient trop grande.
• Point de révocation : Introduisez 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é, tous les jetons d'accès émis à partir de celui-ci ne seront plus renouvelés. Cette méthode fonctionne bien dans les flux OAuth2.

Avantages de l'authentification JWT#

• Rapide et plus informatif : La nature autonome des JWTs rend la vérification côté client plus rapide et plus efficace, sans besoin d'interaction avec le serveur. Ils peuvent également inclure des claims personnalisés (par exemple, les rôles utilisateur ou d'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 JWTs utilisent des techniques de signature et de cryptage, ce qui rend les attaques plus difficiles.
• Support multi-domaines : Les JWTs sont parfaits pour la connexion unique (SSO) et l'authentification multi-domaines. Ils permettent aux utilisateurs de s'authentifier à travers plusieurs domaines ou services avec le même jeton.
• Compatible mobile : Les JWTs 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 efficacité et 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é comme 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 accès aux ressources jusqu'à ce que le JWT expire. De même, si un JWT contient des informations d'autorisation basées sur les rôles, la nouvelle portée d'autorisation ne prendra effet que lorsque l'ancien JWT expirera. En d'autres termes, les JWTs ne conviennent pas à la révocation en temps réel et les utilisateurs peuvent définir un temps d'expiration approprié pour atténuer ce problème.

• Dilemme des appareils multiples et de la révocation

  Il n'est pas possible de valider tous les JWTs émis avant qu'ils expirent pour mettre en œuvre la révocation de l'utilisateur sur 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 JWTs utilisant cette clé, et le processus de gestion des clés de cache rendrait cette approche impraticable pour des opérations simples de révocation de l'utilisateur.

Certains fournisseurs d'identité pourraient avoir des solutions préconçues pour ces problèmes de 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 JWTs 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 leurs inconvénients, elles offrent différents avantages et inconvénients.

Les sessions offrent des garanties plus solides pour l'autorisation des requêtes individuelles et sont plus simples à mettre en œuvre de manière sécurisée. Cependant, leur dépendance à la validation des bases de données côté serveur introduit une surcharge de latence, ce qui peut nuire à l'expérience utilisateur pour les applications fortement réactives.

Les JWTs, en revanche, sont avantageux pour une autorisation plus rapide et une interopérabilité avec des applications externes, mais nécessitent plus d'efforts de développement pour aborder les complexités de sécurité. Par exemple, nous pouvons utiliser des webhooks pour notifier les clients lorsque l'accès de l'utilisateur est révoqué, de manière à ce que les clients puissent effacer le JWT mis en cache et obliger l'utilisateur à se réauthentifier.

Étant donné que l'authentification basée sur les jetons est plus appropriée pour évoluer avec ses 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 par session#

L'authentification par session fonctionne le mieux lorsque vous avez besoin d'un contrôle de session en temps réel, d'une gestion centralisée, ou que l'évolutivité n'est pas une préoccupation majeure. Voici où elle excelle :

• 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 pendant leur visite.

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

  Des 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 robuste des accès et la sécurité.

• Systèmes à serveur unique ou à petite échelle

  Les outils internes ou les applications à petite échelle sans besoins d'évolutivité élevés prospèrent avec une gestion simple des sessions pour une facilité d'utilisation et une fiabilité.

Quand utiliser l'authentification JWT#

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

• Connexion unique (SSO)

  Les JWTs sont parfaits pour la connexion unique, permettant aux utilisateurs de s'authentifier une seule fois et d'accéder en toute transparence à plusieurs services ou applications en utilisant le même jeton. Partagez une explication détaillée sur les applications cloud sécurisées utilisant OAuth 2.0 et OIDC, avec un format JWT pour les jetons d'accès et les jetons ID.

• Applications mobiles

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

• Architectures de microservices

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

• Authentification multi-domaines

  Les JWTs 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 JWTs permettent une authentification à travers les domaines sans dépendances supplémentaires.

• APIs et services web

  Les APIs RESTful et les services web utilisent couramment les JWTs pour l'authentification car ils sont légers, portables, et éliminent le besoin de gestion de session côté serveur. Apprenez-en davantage sur l'authentification machine-à-machine pour les scénarios où votre application doit communiquer directement avec les ressources.

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

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

Gérer les problèmes de déconnexion des utilisateurs avec JWT#

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

• En effaçant les jetons et les 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 sur l'application cliente et le serveur.
• De plus, Logto prend en charge la déconnexion en canal arrière, permettant au AuthServer de notifier toutes les applications clientes partageant la même session lorsqu'un utilisateur se déconnecte.

Cela garantit une gestion cohérente et sécurisée des sessions dans votre écosystème. Apprenez-en plus sur les mécanismes de déconnexion et comment implémenter la déconnexion.

Gérer les changements de permissions des utilisateurs#

Gérer les changements en temps réel des permissions des utilisateurs avec JWT peut également être délicat. Étant donné que les JWTs sont par conception sans état, toutes permissions ou rôles mis à jour peuvent ne pas prendre effet tant que le jeton n'expire pas. Logto propose des stratégies pour aborder cela efficacement :

• Pour réduire les permissions de cet utilisateur : Utilisez des durées d'expiration de jeton d'accès courtes ou vérifiez dynamiquement les permissions via un appel API.
• Pour ajouter de nouvelles permissions à cet utilisateur : Mettez à jour le AuthServer pour inclure la nouvelle portée de permission et re-consentez les utilisateurs pour appliquer ces changements.

Ces solutions aident à maintenir les permissions à jour et garantissent un système plus sûr et plus réactif. Apprenez-en plus sur la gestion des changements en temps réel des permissions des utilisateurs.

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