Aws cognito get jwt token

Intro

Nous avons déjà abordé le processus de récupération des jetons JWT à partir du point de terminaison de jeton Cognito.

📘 Ensuite

, nous devons décoder les jetons pour obtenir les informations qu’ils contiennent, puis vérifier la signature des jetons pour nous assurer qu’ils sont légitimes. Il existe des bibliothèques qui existent juste à cet effet, et parce que nous utilisons Node comme environnement, nous devons trouver une bibliothèque de nœuds.

Ressources

AWS Docs : Vérification d’un jeton Web JSON

Github :auth0/node-jsonwebtoken

Comprendre le JWK

Avant de passer à un exemple complet, assurons-nous rapidement que nous comprenons la théorie qui sous-tend la vérification de la signature d’un JWT. Comme nous le savons, le JWT contient trois sections.

1. Signature

du corps de l’en-tête La signature est ce que nous vérifions pour nous assurer que le jeton provient bien de Cognito et non d’un tiers malveillant menant une attaque de l’homme du milieu (MIM). Nous vérifions la signature à l’aide d’une clé de chiffrement publique que Cognito crée et nous fournit (ceci est décrit plus en détail dans la documentation liée ci-dessus). L’une des choses délicates à comprendre à ce sujet, cependant, est que la clé publique est accessible publiquement . Toute personne disposant de notre identifiant de pool d’utilisateurs peut récupérer cette clé. Donc, si quelqu’un peut récupérer notre clé publique, comment savons-nous qu’une attaque MIM n’utilise pas simplement cette clé pour créer une fausse signature sur le JWT ?

La réponse à cette question est assurée par une compréhension fondamentale de la différence entre les clés privées et publiques.

• Clés publiques : Peut décoder une signature
• Clés privées : Peut décoder et encoder une signature

Ces clés sont créées mathématiquement de telle sorte que seule la clé privée peut encoder quelque chose, tandis que la clé publique peut le décoder. Par conséquent, nous pouvons utiliser la clé publique pour vérifier que la signature a été créée avec la clé privée, à laquelle seul Cognito a accès.

Donc, en bref, il n’y a aucun moyen pour un MIM de falsifier une signature. Un MIM pourrait intercepter et décoder notre signature, ou même voler les informations d’identification et se connecter à notre API, mais il ne pourrait pas falsifier une signature de Cognito.

La possibilité d’intercepter nos jetons est la raison pour laquelle 0Auth2 impose une limite de temps aux jetons d’accès, et pourquoi l’utilisation de connexions sécurisées est si importante.

Décoder le jeton JWT

La bibliothèque node-jsonwebtoken liée ci-dessus a la capacité de décoder et de vérifier le jeton JWT en une seule méthode. Cette méthode prend le format suivant.

À ce stade du processus, nous avons le token, mais nous n’avons pas encore récupéré notre clé publique .

Pour

récupérer la clé, nous construisons une URL au format suivant :

Remplissage des variables de votre région et de l’identifiant de votre pool d’utilisateurs. Ensuite, pour récupérer les clés, nous pouvons simplement faire une requête Postman GET à cette adresse et la réponse que nous obtenons sera deux objets clés au format JSON.

Une seule de ces clés est celle que nous voulons utiliser, nous devons donc déterminer laquelle correspond à l’enfant dans l’en-tête de notre jeton. Nous pourrions utiliser la bibliothèque de nœuds pour le faire de manière programmatique, mais nous n’avons besoin de le faire qu’une seule fois pour que vous puissiez également le faire avec jwt.io.

Et nous pouvons voir que c’était la première clé que nous voulions. Je peux donc l’ajouter à mon code et lui donner une variable.

Tout cela était un point de confusion pour moi auparavant. Lorsque la documentation AWS a indiqué que je devais récupérer la clé publique une fois, je n’étais pas sûr que cela signifiait l’obtenir avec des demandes d’API une fois par session, etc. Mais non, ils signifient en fait UNE FOIS.

Si vous utilisez Express ou un autre framework qui n’affiche pas de SPA statique, vous voudrez probablement mettre cette clé dans des variables d’environnement ou autre chose. Ce projet aura besoin de variables d’environnement à des fins de développement, mais nous n’en sommes pas encore là. Par conséquent, une variable convient pour l’instant.

Donc, à ce stade, nous avons les deux éléments dont nous avons besoin pour que la bibliothèque Github :auth0/node-jsonwebtoken décode et vérifie notre jeton JWT, alors allons-y et faisons-le.

Construisons

maintenant une fonction qui prend les jetons JWT comme argument, puis décode et vérifie les id_token .

Vous remarquerez que nous avons également dû utiliser une autre petite bibliothèque pour convertir le jeton au format PEM, comme le recommandait AWS Docs, et nous avons également dû spécifier l’algorithme. Cependant, nous pouvons voir que cela a fonctionné.

Il y a cependant une petite modification que nous devons apporter à cela. Actuellement, la méthode de vérification utilise simplement la signature pour décoder le contenu, puis vérifie que le jeton n’a pas expiré. Nous devons en fait vérifier les affirmations à l’intérieur du contenu. AWS nous demande de vérifier les allégations d’audience , d’émetteur et d’utilisation des jetons. Pour ce faire, nous ajoutons ces éléments dans les options de la méthode de vérification comme suit.

Et nous avons récupéré en toute sécurité nos informations d’utilisateur vérifiées. Maintenant, parce que nous faisons cela avec React-Redux, nous pouvons enregistrer ces objets dans le magasin, puis les transmettre en tant qu’accessoires à notre pour afficher les informations utilisateur. De plus, nous pouvons enregistrer tous les jetons dans la boutique, car nous aurons besoin de leurs informations pour accéder à notre API.

Commentaires