Gestion de l'expiration / fonctionnalité "remember me" avec JWT

Je ne suis pas si sûr de suivre mais je vais écrire ce que je pense.

imaginez le jeton comme une carte d'hôtel, vous payez à l'avance pour 5 jours (rappelez-vous moi mis à expiration sur 5 jours). Je peux entrer dans le bâtiment, un garage, une chambre, etc. dans ces 5 jours, après ces 5 jours, ça ne marchera plus.

Que faire lorsque le jeton est déjà expiré? Rien du tout.

Imaginez que je paie ces 5 jours et meh, j'ai eu une urgence et je rentre à la maison (avec la carte dans la poche). L'hôtel ne dispose pas de soins du tout, dans les 5 jours qui passent, la carte est juste un morceau inutile de plastique et si vous essayez de l'utiliser sur l'hôtel, il ne fera rien.

alors retour au développement web. Si vous offrez un service me souvenir, vous pouvez mettre une date d'expiration pour disons 7 jours. Aussi longtemps que l'utilisateur a le jeton, il peut accéder au service sans aucun problème. S'il perd le token, il doit se reconnecter. Si il utilise le jeton et il ont expiré, il aura besoin de vous connecter à nouveau.

S'il se connecte, il obtient un token pour 7 jours, s'il ne l'utilise plus et qu'après 20 jours il revient, il aura besoin de se connecter à nouveau, le serveur déclinera juste vos requêtes jusqu'à ce que vous le fassiez.

ce que je ferais si vous utilisiez quelque chose comme angular sur la frontend est de vérifier la validation du token au démarrage pour que vous puissiez avoir une bonne expérience utilisateur.

ce que je ne comprends pas à propos de votre la question est de la mise en cache chose que.

vous avez besoin de persister le JWT sur le client afin qu'il soit disponible à travers les charges de page, la stratégie la plus sûre est un cookie HTTPS-only. Ceci enverra le JWT à votre serveur à chaque requête et le serveur peut vérifier la validité du jeton et le rejeter s'il est expiré. La façon dont vous gérez l'expiration dépend du type d'application web que vous avez.

pour une demande d'une seule page (par exemple angulaire.js apps) vous souhaitez structurer l'application de sorte que il fait une requête initiale du serveur avant de démarrer le reste de l'application. Si le serveur voit que la JWT de cette requête est Expirée, il émettra une réponse 401. Votre application répondrait à cette réponse en rendant un formulaire de connexion. Dans le cas contraire, elle reposerait sur l'hypothèse que la JWT est valide et peut être utilisée pour accéder aux ressources requises. Si, à tout moment, l'app voit un 401 il doit amener l'utilisateur vers le formulaire de connexion.

pour applications web traditionnelles qui rendent leurs pages sur le serveur: pour toute requête ayant une JWT expirée (telle que lue à partir du cookie), le serveur doit émettre une redirection 302 vers un formulaire de connexion.

je pense que ce que vous demandez est de savoir comment invalider un côté serveur JWT pour de longs tokens d'expiration (par exemple la fonctionnalité" Se souvenir de moi")?

j'ai moi-même rencontré ce problème récemment et j'ai fini par utiliser un secret utilisateur unique pour invalider le token, lorsque l'utilisateur tente de valider un token qui a été produit avec un vieux secret, il échouera. Le nom d'utilisateur peut être trouvé dans la vérification JWT pré décodée.

vous pourriez probablement même utiliser les utilisateurs sel de mot de passe pour cela, de cette façon tout JWT courant serait invalidé quand un utilisateur change son mot de passe (en supposant que vous changiez aussi le sel en même temps), cela peut être problématique bien que le hachage de mot de passe et les JWT deviendraient étroitement couplés

je peux penser à un moyen, mais il n'est pas vraiment défini la norme.

qu'en est-il de l'ajout d'un autre type de date d'expiration avec une durée de vie différente aux revendications? Avec deux revendications, nous pouvons traiter la plus courte comme la date d'expiration de l'accès à la ressource, et la plus longue comme la date d'expiration du rafraîchissement, par exemple

{
    "iat": /* current time */,
    "bbf": /* current time + 1 hour -- expired means no resource access */
    "exp": /* current time + 1 week -- expired means cannot refresh */
}

(Note: j'utilise bbf pour la date d'expiration plus courte. Pas de raison spécifique, juste parce qu'il a 3 caractères en longueur.)

ainsi avec" remember me " coché, lorsque l'utilisateur se reconnecte, il peut utiliser le même token pour en demander un nouveau, mais pas pour accéder à la ressource. Avec cela, toutes les données pertinentes sont contenues dans le jeton -- aucun jeton supplémentaire requis.

et enfin, lorsque" remember me "n'est pas coché, il suffit d'utiliser la même durée de vie pour bbf et exp .

en plus de @Jesus answer , vous pouvez penser à mettre en place un système de rafraîchissement des tokens: https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them /

dans l'hôtel-exemple, votre carte d'hôtel (access-token) serait invalide après le temps X, mais à la réception vous pouvez utiliser votre passeport (refresh-token) pour obtenir une nouvelle carte d'hôtel.

vous pouvez stocker le jeton de rafraîchissement dans la base de données avec des données supplémentaires sur l'appareil que l'utilisateur utilise, lui permettant de désactiver l'appareil au cas où il se fait voler.

exemple:

1. première correctes de connexion du client: Créer un jeton d'actualisation qui est valable pour toujours (jusqu'à ce qu'il est supprimé ou invalidé)
2. stocker rafraîchir token dans la base de données
3. JWT (return access token) avec le temps d'expiration au client ( ce jeton n'est pas stocké dans la base de données)

4. pour la requête suivante, le client envoie le jeton d'accès

5. vérifiez maintenant si le jeton d'accès est expiré:

   5.1 Le jeton D'accès n'est pas expiré, tout va bien

   5.2 jeton d'accès expiré, Vérifiez s'il y a un jeton de rafraîchissement dans la base de données

   5.2.1 rafraîchir le jeton est dans la base de données, retourner le nouveau jeton D'accès

   5.2.2 Pas De Rafraîchissement Jeton dans la base de données, de retour 401 / fermeture de session, l'Utilisateur doit se connecter à nouveau

Espérons que cette aide.