AWS API Gateway - Utilisation du jeton d'accès avec un autoriseur Cognito User Pool?
Je configure une application avec plusieurs interfaces (applications Web et mobiles) et un serveur unique, alimentée par Lambda et accessible via AWS API Gateway.
Alors que je prévois d'utiliser Cognito pour authentifier et autoriser des utilisateurs, j'ai configuré un autoriseur Cognito User Pool sur ma passerelle API et plusieurs méthodes d'API.
Avec une telle architecture, il semble logique que mes applications (par exemple, une application iOS ou Vue.js) soient les applications clientes dans une perspective OAuth et que le serveur principal de ma passerelle API soit un serveur de ressources. D'après cet article de forum Auth0 , il semble clair que je devrais donc utiliser un jeton d'identification dans mon application client et transmettre un jeton d'accès pour autoriser les ressources de ma passerelle API.
Lorsque je frappe le noeud final /oauth2/authorize de Cognito pour obtenir un code d'accès et que je l'utilise pour toucher le noeud final /oauth2/token, j'obtiens 3 jetons: un jeton d'accès, un jeton d'identification et un jeton d'actualisation. Jusqu'ici tout va bien, car je devrais avoir ce dont j'ai besoin.
C'est là que j'ai rencontré des difficultés - en utilisant la fonction de test de la console API Gateway de Cognito User Pool Authorizer, je peux coller le jeton ID et le transmettre (décodage du jeton à l'écran). Mais lorsque je colle le jeton d'accès, j'obtiens 401 - unauthorized.
Dans ma configuration de Cognito, j'ai activé uniquement le flux Authorization Code Grant, avec les étendues email et openid (cela semble être le minimum autorisé par Cognito car j'obtiens une erreur en essayant de sauvegarder sans au moins ces cases cochées).
Dois-je ajouter des portées spécifiques pour que API Gateway autorise une demande avec le code d'accès? Si oui, où sont-ils configurés?
Ou est-ce que je manque quelque chose? API Gateway autorisera-t-elle uniquement l'utilisation d'un jeton ID avec un Cognito User Pool Authorizer?
Vous pouvez utiliser un jeton d'accès avec le même autoriseur qui fonctionne pour le jeton id, mais certaines configurations supplémentaires doivent être effectuées dans le groupe d'utilisateurs et dans l'APIG.
Même lorsque cette configuration supplémentaire est terminée, vous ne pouvez pas utiliser la fonctionnalité de test de l'outil de création d'autorisations intégrée avec un jeton d'accès, mais uniquement un jeton d'identification. Solution typique à 80% d'AWS!
Pour utiliser un jeton d'accès, vous devez configurer des serveurs de ressources dans le groupe d'utilisateurs sous App Integration -> Resource Servers, peu importe ce que vous utilisez, mais je suppose que vous utilisez <site>.com pour l'identificateur et que vous avez une étendue appelée api.
Non, allez à la méthode dans APIG et entrez le Method Request pour la méthode. En supposant que cela soit déjà configuré avec un autorisateur testé avec le jeton id, vous ajoutez ensuite <site>.com/api à la section Settings -> OAuth Scopes.
En ajoutant simplement OAuth Scope, il s'assurera que le jeton doit maintenant être un jeton d'accès et qu'un jeton d'identifiant n'est plus accepté.
Ceci est détaillé ici: https://docs.aws.Amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html
Oui, API Gateway utilisera uniquement idToken pour autoriser.
Une fois que l'utilisateur a saisi les informations d'identification correctes, le code d'accès est fourni par le fournisseur d'identité, autorisant l'utilisateur à saisir les informations d'identification correctes. Ce code d'accès est utilisé par le client Uniquement pour vous permettre d'obtenir idToken et refreshToken depuis /oauth2/token pour cet utilisateur donné. Tous vos autres appels utiliseraient uniquement idToken dans l'en-tête Authorization.
Même ce code d'accès expire après que vous ayez récupéré vos jetons d'utilisateur.