Axios get jwt token

Nous voulons implémenter l’authentification des requêtes HTTP sortantes avec JWT dans une configuration multi-tenant.

Notre exemple de service de tâches fonctionne dans un environnement de microservices avec multi-tenant. Un utilisateur utilise un JWT pour s’authentifier auprès de l’ensemble de l’environnement de microservices, mais uniquement pour un espace de travail. Une autorité émet des JWT pour l’environnement de microservices. Le JWT contient l’ID d’espace de travail que tous les services doivent prendre en compte pour limiter l’étendue de fonctionnement de l’utilisateur.

Supposons qu’un utilisateur effectue une requête HTTP à notre service en s’authentifiant avec un JWT. Ensuite, notre service pourrait utiliser ce JWT pour s’authentifier auprès d’autres services dans l’environnement de microservices.

toutefois.

Cette approche pose plusieurs problèmes :

• elle limite les interactions de notre service avec d’autres services à ce que l’utilisateur est autorisé à faire.
• Il nous lie à la délai d’expiration du JWT. Nous ne pouvons pas faire de demandes après cela.
• D’autres services ne peuvent pas faire la distinction entre les demandes de notre service et les demandes de l’utilisateur. Ces services peuvent nous appliquer une limitation de débit parce qu’ils pensent que notre service est l’utilisateur.

Pour contourner ces problèmes, nous demandons des JWT distincts qui authentifient notre service en tant que lui-même. En fonction de la nature de notre demande, nous demandons un champ d’application différent pour le JWT.

• Pour la majorité des demandes, nous voulons avoir un JWT limité à l’espace de travail de l’utilisateur.
• Pour certaines demandes, nous voulons disposer d’un JWT capable d’agir sur plusieurs espaces de travail.
• Pour d’autres demandes, nous pouvons souhaiter disposer d’un JWT qui agit non seulement dans un espace de travail, mais également avec les autorisations de l’utilisateur.

Lors 🔗

de la suppression d’un todo, nous envoyons une requête HTTP au service de notification pour créer une notification. La tâche est supprimée dans un espace de travail et la notification doit être créée dans le même espace de travail.

Le point de terminaison nécessite un en-tête avec un JWT limité à un espace de travail.

Nous avons déjà un module avec une fonction qui encapsule la logique d’envoi de cette requête sans authentification. Nous pourrions récupérer un JWT ici et le passer à Axios dans l’en-tête.

Cependant, cela expose des détails sur l’authentification à chaque module envoyant des requêtes HTTP. De plus, dans chacun de ces tests, nous aurions toujours besoin de simuler la fonction .

Au lieu de cela, nous voulons uniquement passer le champ d’application souhaité du JWT. Nous laissons à un intercepteur Axios le soin de récupérer le JWT et d’y attacher l’en-tête d’autorisation.

Le type 🔗 d’accès au service

Dans un module, nous définissons les différentes options qui peuvent être passées en paramètre à une requête Axios.

Nous autorisons la transmission d’un objet pour exprimer un accès complet entre les espaces de travail. Un objet exprime l’accès à un espace de travail. De plus, nous pourrions définir l’accès utilisateur avec . Nous laissons cette option de côté pour plus de simplicité.

De plus, dans le même module, nous créons deux constructeurs.

L’utilisation de ces constructeurs garantit qu’un objet d’accès au service valide est transmis à l’intercepteur Axios.

Vous souhaitez lire plus de messages de ce type ?

Récupération d’un JWT 🔗

Nous ajoutons un module pour récupérer un JWT. Cette logique peut varier considérablement en fonction de votre façon d’émettre des jetons.

Dans cette configuration, il existe un service avec un point de terminaison . A partir de la configuration, notre service reçoit un ID client et une clé secrète client.

Pour plus d’informations à ce sujet, consultez 'Gérer les configurations avec du code TypeScript dans Node.js'

Nous utilisons l’ID client et le secret pour Authentifiez-vous avec l’authentification de base auprès du service. De cette façon, le service d’authentification reconnaît notre service et lui permet d’émettre le JWT.

Avec le paramètre , nous décidons des permissions que le JWT doit avoir. Si la valeur est , le JWT n’est pas limité à un seul espace de travail. Si la valeur est , le JWT est limité à l’espace de travail.

Mise en cache du JWT 🔗

Nous voulons éviter de demander un nouveau JWT à chaque requête HTTP entrante. Pour plus de rapidité, pour éviter la charge sur l’émetteur du jeton et pour éviter une source d’erreurs HTTP.

Il existe un package npm qui met en cache la valeur de retour d’une fonction étant donné que les paramètres d’entrée sont identiques.

Dans le même module , nous créons une fonction . Il met en cache le JWT de la fonction pendant 50 minutes. Cette fois, on suppose qu’un JWT devient invalide au bout de 60 minutes. Vous pouvez ajuster ce délai en fonction du délai d’expiration de JWT dans votre configuration.

Nous testons cette fonction pour assembler correctement une demande JWT.

Nous créons un intercepteur Axios qui est appelé avant chaque requête sortante. Nous enregistrons cet intercepteur dans la fonction qui est appelée dans la fonction du programme.

L’intercepteur réside dans le module .

S’il détecte que l’objet passé n’est pas valide, il ne fait rien. S’il détecte que l’en-tête est déjà défini, il ne fait rien non plus.

Remarque : Il est crucial qu’un en-tête existant ne soit pas remplacé. Dans le cas contraire, l’authentification de base pour la récupération JWT serait remplacée.

Si l’objet est valide et que l’en-tête n’est pas encore défini, l’intercepteur récupère le JWT avec la portée demandée. Une fois la récupération réussie, l’intercepteur joint l’en-tête à la demande.

Nous pouvons vérifier les différents scénarios avec Plaisanterie.

Moquerie sur l’environnement 🔗 local

Dans un article précédent, nous avons configuré la simulation des requêtes adressées à d’autres services localement.

Pour plus d’informations à ce sujet, consultez 'Organiser et tester les requêtes HTTP'

Dans le dossier , nous créons un fichier . Ce fichier est interprété comme la réponse aux demandes adressées au point de terminaison.

Localement, nous envoyons toujours le JWT renvoyé au serveur fictif. Par conséquent, il suffit qu’il décode en une charge utile factice.

Conclusion 🔗

Nous avons ajouté un intercepteur de requêtes à Axios pour ajouter un en-tête. Cet en-tête est renseigné avec un JWT avec l’étendue spécifiée. Pour chaque étendue, le JWT est mis en cache jusqu’à 10 minutes avant l’expiration. Localement, nous nous moquons de la récupération du JWT pour renvoyer un JWT factice.