Flux de travail de service à service avec AWS cognito et AWS Lambda

Question

Je suis plutôt novice en matière de AWS Cognito et AWS Lambda. Jusqu'à présent, j'ai joué avec Serverless et déployé mon API REST via AWS Lambda. Cependant, j'aimerais mettre mon API à la disposition de plusieurs parties externes. Comme il s'agit d'un service à service, il n'y a pas d'utilisateur final qui appelle directement mon API. Je mets l'API à la disposition d'autres entreprises qui l'utilisent dans leurs applications. Toutes les fonctionnalités exposées via l'API sont plutôt simples, ce qui signifie qu'elles n'invoquent pas d'autres services AWS comme une base de données Dynamo, etc.

J'ai plusieurs questions, certaines sont plutôt de haut niveau, d'autres sont assez spécifiques à la configuration d'AWS Cognito. J'ai décidé de tout regrouper dans un seul post, car cela rend le tout beaucoup plus autonome et plus facile à comprendre.

1. Question, Cognito vs clé API : Quel est l'avantage d'utiliser AWS Cognito par rapport à AWS Lambda en combinaison avec la restriction de l'accès via une clé API et une liste blanche d'adresses IP ? L'un est-il beaucoup plus sûr que l'autre ?

Supposons que je veuille utiliser AWS Cognito. Comme il s'agit d'un cas de service à service, j'ai lu que la norme est d'utiliser des points de terminaison à jeton où l'adresse de l'utilisateur est la suivante grant_type est client_credential . J'ai trouvé ce qui suit sur moyen . Les premières étapes consistent à

1. Créez un pool d'utilisateurs dans AWS Cognito.
2. Créer un client App
3. Ajouter des serveurs de ressources
4. Activez le client credentials la case à cocher pour Allower OAuth flows

2. Question, App client : Dans le client d'application ajouté, je trouve l'adresse correspondante App client id y App client secret . Si j'expose mon API à plusieurs parties différentes, dois-je ajouter pour chaque partie un autre client d'application ? Sinon, ils utilisent tous les mêmes informations d'identification. Est-ce la bonne façon de procéder ?

3. Question, serveur de ressources : Ici, je suis complètement coincé. Quelle est la signification exacte de ceci ? En fin de compte, tout ce que je veux, c'est que mes clients puissent faire une requête post contre mon API et que l'accès soit accordé par Cognito. Une clarification de la signification et de la manière dont cela s'applique à mon cas serait appréciée. Je serais ravi de vous faire part d'autres informations si nécessaire.

La partie suivante consiste à configurer Cognito Authorizer pour la passerelle API. Cela devrait être parfait.

4. Question, flux de travail du client En ce qui concerne le flux de travail de mes clients. Ai-je raison de dire que cela consiste en les étapes suivantes :

1. D'abord, je fournis au client son client_id y client_secret .

alors le client met en œuvre de son côté le flux de travail suivant :

1. Chaque fois qu'il veut utiliser mon API exposée via API Gateway, il utilise d'abord l'API qu'il a fournie. client_id y client_secret pour récupérer son jeton de porteur.
2. Il utilise ce jeton de porteur pour faire une demande à API Gateway avec le jeton de porteur dans l'adresse IP. Authorization en-tête.
3. Si l'accès est accordé, le client récupère le résultat de mon API.

Est-ce correct ou est-ce que je manque quelque chose ?

Answer 1

1-Question, Cognito vs clé API

Eh bien, comme vous pouvez le voir aquí .

Pools d'utilisateurs Amazon Cognito vous permettent de créer une authentification personnalisable et d'autorisation personnalisables pour vos API REST.

Plans d'utilisation vous permettent de fournir des clés API à vos clients - et ensuite suivre et limiter l'utilisation de vos étapes et méthodes d'API pour chaque clé d'API.

Le but est donc différent, la clé API est utilisée essentiellement pour compter l'utilisation d'un client tandis que AWS Cognito est là pour authentifier/autoriser les appels à votre API.

Disons que vous avez une exigence selon laquelle un utilisateur de piste ne peut pas appeler votre API plus de 100 fois.

Ensuite, à l'aide d'AWS Cognito, vous autoriserez un utilisateur à s'inscrire, vous fournirez également à ce même utilisateur une clé API, vous identifierez la source des appels à l'aide de Cognito et, à chaque appel, API Gateway diminuera de 1 la limite attribuée à la clé API de l'utilisateur.

Et vous aurez les cas suivants :

1. un jeton (obtenu en se connectant à l'aide d'un nom d'utilisateur et d'un mot de passe), et API Key sont valides, alors l'appel sera réussi.
2. Si le jeton est incorrect/manquant, votre interlocuteur obtiendra le code d'état 401.
3. Si la clé API est incorrecte/manquante, votre interlocuteur obtiendra un code d'état 403.
4. Lorsque la clé API est correcte mais que la limite est dépassée, votre appelant obtiendra un code d'état 429.

2. Question, App client :

Eh bien, les identifiants et les secrets de client sont destinés à identifier un client de confiance (application) plutôt qu'un utilisateur et chaque application devrait avoir son propre identifiant de client, donc si l'appelant est une application et non un utilisateur, alors oui, créez un identifiant de client pour chaque application distincte. Veuillez noter que les secrets de client doit doit rester confidentiel. Si l'application appelante ne peut pas le faire, comme les applications Javascript à page unique ou les applications natives, le secret ne doit pas être émis.

3. Question, serveur de ressources :

C'est votre serveur API.

Vérifiez ceci page .

Le serveur de ressources est le terme OAuth 2.0 pour votre serveur d'API. Le serveur de ressources serveur de ressources traite les demandes authentifiées après que l'application a obtenu un jeton d'accès.

Les déploiements à grande échelle peuvent avoir plus d'un serveur de ressources. Les services de Google, par exemple, disposent de dizaines de serveurs de ressources, tels que comme la plateforme Google Cloud, Google Maps, Google Drive, Youtube, Google+, et bien d'autres encore. Chacun de ces serveurs de ressources est distincts, mais ils partagent tous le même serveur d'autorisation.

4. Question, flux de travail du client

Vérifier l'octroi des informations d'identification du client dans aquí

Les étapes du processus sont les suivantes :

An app makes a POST request to https://AUTH_DOMAIN/oauth2/token, and specifies the following parameters:
    grant_type – Set to “client_credentials” for this grant type.
    client_id – The ID for the desired user pool app client.
    scope – A space-separated list of scopes to request for the generated access token.

In order to indicate that the app is authorized to make the request, the Authorization header for this request is set as “Basic

BASE64(CLIENT_ID:CLIENT_SECRET)", où BASE64(CLIENT_ID:CLIENT_SECRET) est la représentation base64 de l'ID du client de l'application et du secret du client de l'application. l'ID du client de l'application et le secret du client de l'application, concaténés avec deux points. Le serveur d'autorisation Amazon Cognito renvoie un objet JSON avec les clés suivantes : access_token - Un jeton d'accès valide au pool d'utilisateurs. expires_in - La durée de validité (en secondes) du jeton d'accès fourni. token_type - Défini sur "Bearer".

Note that, for this grant type, an ID token and a refresh token aren’t returned.
The app uses the access token to make requests to an associated resource server.
The resource server validates the received token and, if everything checks out, executes the request from the app.