Autorisation pour la passerelle API de prendre en charge le stockage des informations d'identification de l'utilisateur

Question

J'ai un service Web auquel les utilisateurs peuvent se connecter, etc. Je souhaite configurer AWS API Gateway pour permettre aux utilisateurs d'interagir avec le service via des API. Comme la gestion des utilisateurs/mot de passe est déjà dans le système, je ne veux pas que l'utilisateur doive aller à un autre système. J'ai d'abord regardé les pools d'utilisateurs de Cognito mais je n'ai pas pu automatiser complètement le processus de création/vérification de l'utilisateur, AWS dans un ticket de support a déclaré que l'utilisateur devrait vérifier l'email séparément. Ils ont ensuite suggéré d'utiliser une fonction Lambda pour configurer l'autorisation.

J'ai créé une fonction Lambda et la passerelle API autorise mais il semble qu'une seule variable soit envoyée pour autorisation, la Identity token. Si je l'ai fait, ma fonction Lambda pourrait trouver dans mon service que la clé est valide mais pas vraiment associée à un utilisateur. Ce que je cherche est un moyen de fournir à un utilisateur un identifiant client et un mot de passe de mon système (je peux générer tout cela), l'utilisateur envoie ensuite une requête au point de terminaison API Gateway avec l'ID client et passkey, la passerelle envoie l'ID client et le mot de passe à la fonction lambda qui appelle mon système pour vérification, Lambda renvoie la politique valide, API Gateway envoie ensuite la demande à mon service avec l'ID client ou un autre identifiant qui revient du politique afin que mon système connaisse le client demandeur.

Quelle serait la meilleure façon d'y arriver sans amener l'utilisateur à un système séparé (Cognito)?

Answer 1

Il se trouve que votre timing aurait pu être juste un jour ou si tôt. Ce que vous auriez déjà expérimenté avec les autorisateurs personnalisés est l'autorisateur TOKEN. Aujourd'hui, ils ont remarqué un support étendu pour les autorisateurs personnalisés avec un nouveau type d'autorisateur REQUEST. Le nouveau type REQUEST prend en charge un ensemble de données beaucoup plus étendu pour autoriser les demandes, telles que les paramètres de requête, les en-têtes, les chaînes de requête, etc. Consultez le Custom authorizer types pour plus d'informations.