Jeton de session api

Lorsqu’un utilisateur visite votre application, vous ne devez pas avoir à se connecter à chaque fois. Après s’être connecté une fois, votre application doit enregistrer des données sur l’utilisateur et lui permettre de reprendre là où il s’était arrêté lors de sa prochaine visite. C’est ce qu’on appelle une session. Auth.js prend en charge 2 stratégies de session principales , la session basée sur JWT et la session de base de données.

Vous pouvez configurer la stratégie de session à l’aide de l’option du fichier de configuration principal Auth.js.

Les Auth.js de session JWT

peuvent créer des sessions à l’aide de jetons Web JSON (JWT). Il s’agit de la stratégie de session par défaut pour Auth.js sauf si un fournisseur de base de données est configuré. Lorsqu’un utilisateur se connecte, un JWT est créé dans un fichier . , par exemple), ce qui rend plus difficile pour les attaquants de voler la valeur. De plus, le JWT est chiffré à l’aide d’une clé secrète connue uniquement du serveur. Combiné à un délai d’expiration court, cela fait des JWT un moyen sûr de créer des sessions.

Lorsqu’un utilisateur se déconnecte, Auth.

Les

• JWT en tant que session ne nécessitent pas de base de données pour stocker les sessions, ce qui peut être plus rapide, moins coûteux et plus facile à mettre à l’échelle.
• Cette stratégie nécessite moins de ressources, car vous n’avez pas besoin de gérer une base de données/un service supplémentaire.
• Vous pouvez ensuite utiliser le jeton créé pour transmettre des informations entre les services et les API du même domaine sans avoir à contacter une base de données pour vérifier les informations incluses.

Inconvénients

• Il n’est pas possible d’expirer un jeton Web JSON avant son expiration encodée. Il faut donc maintenir une liste de blocage côté serveur des jetons invalidés (au moins jusqu’à ce qu’ils expirent vraiment) et vérifier chaque jeton par rapport à la liste chaque fois qu’un jeton est présenté. Auth.js le fera (des délais d’expiration de session plus courts sont utilisés lors de l’utilisation de jetons Web JSON comme jetons de session pour permettre l’invalidation plus précoce des sessions et simplifier ce problème.)
• Auth.js active des fonctionnalités avancées pour atténuer les inconvénients de l’utilisation de délais d’expiration de session plus courts sur l’expérience utilisateur, notamment la rotation automatique des jetons de session, l’envoi facultatif de messages persistants (interrogation de session) pour empêcher les sessions de courte durée d’expirer si une fenêtre ou un onglet est ouvert, la revalidation en arrière-plan et la synchronisation automatique des onglets/fenêtres qui maintient les sessions synchronisées entre les fenêtres chaque fois que l’état de la session change ou qu’une fenêtre ou un onglet gagne ou perd le focus.
• Comme pour les jetons de session de base de données, les jetons Web JSON sont limités à la quantité de données que vous pouvez y stocker. Cependant, étant donné que ces données doivent être transmises à chaque demande, vous devez savoir combien de données vous souhaitez transférer en utilisant cette technique.
• Même si elles sont correctement configurées, les informations stockées dans un JWT chiffré ne doivent pas être considérées comme impossibles à déchiffrer à un moment donné, par exemple en raison de la découverte d’un défaut ou des progrès technologiques. Les données stockées dans un jeton Web JSON (JWE) chiffré peuvent être compromises à un moment donné. Il est recommandé de générer un secret avec une entropie élevée.

À

la place d’une stratégie de session JWT, Auth.js prend également en charge les sessions de base de données. Dans ce cas, au lieu d’enregistrer un JWT avec les données de l’utilisateur après vous être connecté, Auth.js créerez une session dans votre base de données. Un ID de session est ensuite enregistré dans un Ainsi, chaque fois que vous essayez d’accéder à la session utilisateur, vous interrogez la base de données pour les données.

Les

• sessions de base de données peuvent être modifiées à tout moment côté serveur, de sorte que vous pouvez mettre en œuvre des fonctionnalités qui pourraient être plus difficiles - mais pas impossibles - en utilisant la stratégie JWT, etc. : « déconnectez-vous partout », ou limitant les connexions simultanées
• Auth.js n’a pas d’avis sur le type de base de données que vous utilisez ; nous avons une longue liste d’adaptateurs de base de données officiels, mais vous pouvez également implémenter les vôtres

InconvénientsLes

• sessions de base de données ont besoin d’un aller-retour vers votre base de données, elles peuvent donc être plus lentes à grande échelle à moins que vos connexions/bases de données ne soient prises en charge pour cela
• De nombreux adaptateurs de base de données ne sont pas encore compatibles avec le dispositif Edge, ce qui permettrait une récupération
• de session plus rapide et moins coûteuse La mise en place d’une base de données demande plus d’efforts et nécessite des services supplémentaires à gérer par rapport à la stratégie JWT sans état