Authentification sans état avec JWT: le jeton d'actualisation n'est pas sans état
Dans mon architecture actuelle, mon backend envoie un JWT au client (mobile). La principale raison d'opter pour un JWT est l'authentification sans état, c'est-à-dire que le serveur n'a pas besoin de stocker les données dans la session/base de données, ce qui signifie moins de problèmes de surcharge et d'évolutivité.
Une stratégie courante consiste à se connecter à l'utilisateur et à renvoyer le JWT de courte durée (environ 15 minutes - comme je l'ai lu), avec un jeton d'actualisation que l'utilisateur stocke dans le client. Le jeton d'actualisation n'expire jamais et ne peut être révoqué que. Le but serait d'éviter d'envoyer trop souvent un JWT à longue durée de vie sur le câble et de ne rafraîchir le JWT qu'une fois expiré; lorsqu'un attaquant prend possession du jeton de courte durée, la fenêtre de temps d'attaque est brève.
Le problème est que cette histoire semble être pleine de trous quand j'y pense. Veuillez m'aider à clarifier.
- Un délai d'expiration de 15 minutes signifierait que certains utilisateurs pourraient tout aussi bien envoyer un jeton d'actualisation sur le câble 10 fois/jour. Cela pourrait être une fréquence aussi élevée que certains utilisateurs feraient des demandes avec un jeton d'accès régulier et de courte durée. Par conséquent, l'argument du jeton d'actualisation semble discutable.
- Si vous remettez en question SSL, je ne sais pas pourquoi tant d'entreprises utilisent l'authentification de base. Pour utiliser JWT avec un jeton d'actualisation, vous devriez probablement utiliser HTTPS de toute façon.
- Quel est l'avantage de JWT si vous devez ensuite stocker un jeton d'actualisation dans la session/base de données afin d'émettre un nouveau jwt au client. Dans ce cas, le jeton d'actualisation agirait comme une sorte de mot de passe (bien que je réalise que ce n'est pas exactement le même) qui est stocké dans le backend. Cela rend le flux d'authentification essentiellement dynamique et semble retirer complètement l'avantage d'utiliser JWT. En outre, avec une brève période d'expiration de 15 minutes, cela signifie que vous avez beaucoup de frais généraux, vous devez obtenir un jeton d'accès actualisé presque chaque fois que vous vérifiez votre téléphone s'il y a un intervalle de 30 minutes. Non seulement il y a la surcharge pour vérifier le jeton d'actualisation stocké, mais vous devez également vérifier si le jeton d'actualisation est sur liste noire, ce qui signifie une autre surcharge de performance. (Modifier: la dernière vérification peut être supprimée en supprimant simplement le jeton d'actualisation de la base de données lorsqu'il est révoqué).
- Un jeton d'actualisation nécessite plusieurs allers-retours sur le serveur:
- 401 est renvoyé lorsque le jeton d'accès a expiré (serveur de ressources).
- Un nouveau jeton d'accès doit être demandé sur le serveur d'authentification
- La demande au serveur de ressources doit être relancée.
Quelqu'un peut-il m'expliquer ce qui me manque ici?
L'une des principales critiques des jetons de session sans état est l'absence de déconnexion sécurisée. Avoir un jeton d'accès/d'actualisation séparé permet un compromis. Vous pouvez réduire considérablement la quantité d'accès à la base de données, tout en disposant d'une fonction de déconnexion sécurisée avec un délai de 15 minutes.
La conception ne fait rien pour protéger contre le détournement de session, c'est-à-dire la capture malveillante du jeton. Utilisez simplement SSL, il est omniprésent de nos jours.
Vous pouvez réduire le nombre de voyages aller-retour avec un certain soin. De nombreuses bibliothèques HTTP clientes vous permettent d'effectuer une authentification proactive, ce qui évite l'aller-retour supplémentaire pour obtenir un 401.
Je suis d'accord que ce n'est pas une conception particulièrement sensée. La plupart des sites Web sont lourds de toute façon, donc vérifier un jeton sur chaque demande n'est pas beaucoup plus lourd. Et bien que le concept de base des jetons d'accès/d'actualisation soit sécurisé, je crains que la complexité supplémentaire n'invite à des failles d'implémentation.
À moins qu'il n'y ait d'autres réponses à cette question, ma propre solution actuelle est qu'il s'agit d'évaluer les compromis entre risque de sécurité et performance.
Ma principale considération est d'augmenter la fenêtre temporelle du jeton d'accès JWT "de courte durée" de 15 minutes à un jour.
Cela étant donné que HTTPS est requis et que les demandes ne sont effectuées qu'en interne, c'est-à-dire que les jetons ne voyagent pas entre les domaines.
Cela signifie qu'en termes de performances, l'actualisation du jeton ne se produit qu'une fois par jour. Théoriquement, SSL devrait fournir une sécurité suffisante dans mon cas; une seule journée de fenêtre d'attaque n'est qu'une mesure de sécurité en plus de quelque chose qui ne devrait pas se produire en premier lieu.
Bien que les jetons d'actualisation rendent essentiellement le processus d'authentification avec état, cela peut être acceptable car la plupart des demandes (dans ce cas sur une journée) au serveur de ressources se produisent toujours en utilisant le jwt.