Le rafraîchissement d'un jeton JWT expiré est-il une bonne stratégie?
Si je comprends les meilleures pratiques, JWT a généralement une date d'expiration de courte durée (~ 15 minutes). Donc, si je ne veux pas que mon utilisateur se connecte toutes les 15 minutes, je dois actualiser mon jeton toutes les 15 minutes.
J'ai besoin de maintenir une session valide pendant 7 jours (point de vue UX), j'ai donc deux solutions:
- utiliser un jeton web json à longue durée de vie (1 semaine) - mauvaise pratique?
- obtenir un nouveau jeton web json après l'expiration de l'ancien (JWT 15min, rafraîchissement autorisé pendant 1 semaine)
Je force l'utilisation de HTTPS.
Le norme JWT ne parle pas de rafraîchissement des jetons. Actualiser un jeton expiré est-il une bonne stratégie?
L'actualisation d'un jeton est effectuée pour confirmer avec le service d'authentification que le détenteur du jeton dispose toujours de droits d'accès. Cela est nécessaire car la validation du jeton se fait via des moyens cryptographiques, sans avoir besoin de contacter le service d'authentification. Cela rend l'évaluation des jetons plus efficace, mais rend impossible la rétractation des droits d'accès pendant la durée de vie d'un jeton.
Sans rafraîchissement fréquent, il est très difficile de supprimer les droits d'accès une fois qu'ils ont été accordés à un jeton. Si vous effectuez la durée de vie d'un jeton par semaine, vous devrez probablement implémenter un autre moyen pour gérer, par exemple, la suppression d'un compte d'utilisateur, le changement de mot de passe (ou tout autre événement nécessitant une reconnexion) et un changement des autorisations d'accès. pour l'utilisateur.
Donc, respectez les intervalles de rafraîchissement fréquents. Une fois toutes les 15 minutes ne devrait pas suffire à nuire aux performances de votre service d'authentification.
Modifier 18 novembre 2019: Par @Rishabh Poddar commentaire, vous devez générer un nouveau jeton d'actualisation à chaque fois que l'ancien est utilisé. Voir ceci discussion approfondie de la gestion de session pour plus de détails.
Vous devez actualiser le jeton toutes les 15 minutes, mais vous n'avez pas besoin de laisser l'utilisateur s'authentifier à nouveau pour le faire.
- Après l'authentification, distribuez un JWT valable pendant 15 minutes.
- Laissez le client actualiser le jeton chaque fois qu'il expire. Si cela est fait dans les sept jours, un nouveau JWT peut être obtenu sans réauthentification.
- Après qu'une session est inactive pendant sept jours, exigez une authentification avant de distribuer un nouveau jeton JWT.
De cette façon, vous pouvez par exemple exiger une authentification après qu'un utilisateur a changé son mot de passe.
Vous pouvez obtenir le jeton d'accès configuré pendant 7 jours lorsque l'utilisateur s'authentifie. Cependant, ce ne sera pas la meilleure pratique en matière de sécurité, car il serait plus difficile de révoquer l'accès si nécessaire. Bien sûr, cela dépend de vos besoins, mais la meilleure pratique consiste également à obtenir le jeton d'actualisation et à l'utiliser pour actualiser le jeton d'accès à chaque période.
Ma configuration est ..
Lorsque quelqu'un se connecte, générez un JWT avec une exp de 5 jours, avec un champ personnalisé, utilisezExp de 10 minutes
Quand quelqu'un fait une demande authentifiée, useExp doit être dans le futur, à moins qu'il ne demande un nouveau jeton
Quand quelqu'un fait une demande authentifiée pour un nouveau jeton, useExp peut être dans le passé, mais l'exp doit être dans le futur. S'il est valide, je vais leur générer un nouveau jeton comme s'ils venaient de se connecter.
Si les deux exp sont dans le passé, ils doivent faire une demande non authentifiée pour se connecter avec leur email et mot de passe.
Il semble que vous utilisiez des JWT pour la gestion des sessions. Ce avec quoi vous luttez est un problème typique qui survient avec ce schéma d'authentification. Les JWT ne sont pas idéaux pour les exigences de gestion de session. Vous avez besoin de diverses astuces pour maintenir la session en vie plus longtemps (comme d'autres décrites), pour révoquer des droits ou vous déconnecter. Voici un article qui décrit les compromis vous devez faire face à cette configuration.
Si vous pouvez vivre avec les compromis, les JWT sont acceptables pour la gestion des sessions. Si vous avez besoin d'un contrôle plus précis, jetez un œil aux schémas de gestion de session basés sur les cookies.
En règle générale, pour les JWT, vous disposerez d'un jeton access, qui est valide pendant environ 15 minutes, et d'un jeton refresh qui est valide plus longtemps (par exemple, 24 heures).
Pour accéder aux points de terminaison de l'API, le navigateur envoie uniquement le jeton access. S'il reçoit un état HTTP 401, il actualise ensuite son jeton en soumettant le jeton refresh à un point de terminaison spécifié, récupère deux nouveaux jetons (actualisation et accès) et continue le long.
Voici la chose merveilleuse. Les deux jetons ont des dates d'expiration, les deux jetons sont signés - vous devez donc toujours valider tous les jetons (indépendamment de l'accès ou de l'actualisation) en utilisant la même logique, avant d'effectuer une validation spécifique au jeton.
Pour ceux qui ont mentionné deux JWT ( @ keithRozario@ Sjoerd ) ou un JWT mais deux champs ( @ Michael Baldry@ Laurens Rietveld ):
Appelons les deux JWT ou deux champs access token et refresh token.
Si le pirate obtient le jeton d'accès d'une manière ou d'une autre, il est très probable que le jeton d'actualisation soit également divulgué et le pirate peut demander le jeton d'accès en utilisant le jeton d'actualisation. En ce sens, la courte expiration du jeton d'accès n'aide pas beaucoup ici.
quelqu'un a suggéré qu'une liste de révocation soit conservée côté serveur afin que chaque demande d'actualisation du token soit vérifiée. Eh bien, l'une des principales raisons pour lesquelles les gens utilisent JWT est que le serveur n'a pas besoin de maintenir la session, il est donc plus évolutif. L'idée de maintenir la liste de révocation ne brise-t-elle pas cet avantage?
Une façon de penser est d'ajouter un autre champ au jeton d'accès pour restreindre l'actualisation du jeton, disons 30 minutes. Il peut donc atténuer la perte même en cas de fuite du jeton d'accès et du jeton d'actualisation. Mais je ne sais pas si c'est une bonne pratique ou non.