Comment fonctionne l'authentification par jeton avec les services Web à charge équilibrée

Question

Nous utilisons la sécurité basée sur les jetons sur certains de nos services Web ArcGIS Server et j'essaie de mieux comprendre leur fonctionnement. Nous devons actuellement utiliser des sessions persistantes car nous avons des services équilibrés en charge pour la redondance et la performance. Cependant, toute la documentation que j'ai lue (l'article ci-dessous par exemple) suggère que l'utilisation de l'authentification par jeton devrait réellement supprimer le besoin de sessions persistantes. Après toutes les lectures que j'ai faites, je ne sais toujours pas pourquoi c'est le cas.

Si un utilisateur se connecte et reçoit un jeton de l'un de nos serveurs à équilibrage de charge et que le jeton est passé avec chaque requête suivante, pourquoi ne devrait-il pas être nécessaire que la requête aboutisse sur le même serveur. Comment l'autre serveur pourrait-il authentifier le jeton? La seule façon que je peux penser d'après mes lectures que cela pourrait être fait pour fonctionner sans sessions collantes est de stocker la signature de jeton dans un référentiel central disponible pour tous les serveurs à charge équilibrée. Là encore, ce n'est pas si différent de simplement stocker le jeton lui-même qui est le même que stocker des informations de session.

http://code.tutsplus.com/tutorials/token-based-authentication-with-angularjs-nodejs--cms-22543

Answer 1

La seule façon que je peux penser à partir de mes lectures que cela pourrait être fait travailler sans sessions collant est de stocker la signature symbolique dans un référentiel central disponible pour toute la charge équilibrée les serveurs.

Oui, c'est correct. L'article lié affiche un magasin de jetons persistant. La seule exception à cette règle est que les JWT sont utilisés (également dans l'article lié) ou un mécanisme similaire qui ne stocke pas les jetons côté serveur. Cela est dû au fait que, même si le nom d'utilisateur se trouve dans le JWT qui pourrait être stocké dans le cookie côté client, le nom d'utilisateur est protégé par un MAC. Ce code d'authentification de message hache le nom d'utilisateur avec un secret côté serveur. Ce secret peut être partagé entre tous les serveurs à charge équilibrée, et réexécuter l'algorithme MAC peut garantir que le nom d'utilisateur stocké côté client n'a pas été altéré. En pratique, n'oubliez pas de toujours stocker une date d'expiration, sinon votre JWT sera vulnérable aux attaques de relecture (par exemple, un utilisateur valide enregistrant sa valeur de cookie pour une utilisation ultérieure s'il n'a pas accès à cet utilisateur).