参考

Question

我们正在寻求利用AWS Cognito通过以下架构进行身份验证： client (browser) -> our server -> AWS Cognito

设置了各种配置后，initiateAuth似乎与AdminInitiateAuth没什么不同，因此我想了解在这些配置下，是否选择一个优先于另一个。

似乎当我使用client secret创建应用并使用initiateAuth时，似乎与使用adminInitiateAuth身份验证的ADMIN_NO_SRP_AUTH的集成体验几乎相同流。后者甚至不需要AWS文档中所述的AWS凭证。我与Cognito的集成如下：

initiateAuth ：

  const payload = {
    AuthFlow: "USER_PASSWORD_AUTH",
    ClientId: cognitoClientId,
    AuthParameters: {
      USERNAME: username,
      PASSWORD: password,
      SECRET_HASH: generateSignature(username)
    }
  }
  const response = await cognitoClient.initiateAuth(payload).promise();

adminInitiateAuth ：

  const payload = { 
    UserPoolId: userPoolId,
    AuthFlow: "ADMIN_NO_SRP_AUTH",
    ClientId: cognitoClientId,
    AuthParameters: {
      USERNAME: username,
      PASSWORD: password,
      SECRET_HASH: generateSignature(username)
    }
  }
  const response = await cognitoClient.adminInitiateAuth(payload).promise();

您可以看到的区别是不同的AuthFlow值，调用不同的方法以及ADMIN_NO_SRP_AUTH需要使用UserPoolId参数，这对我来说似乎很肤浅。

我们还将根据客户机密生成签名，这是我们将安全处理的事情。

Answer 1

我了解您想了解Amazon Cognito中的InitiateAuth和AdminInitiateAuth API调用之间的区别。要澄清API调用的用法：

InitiateAuth是客户端/浏览器端的API调用，该API调用不需要任何敏感的凭据即可提出质询和其他参数。
AdminInitiateAuth是要在服务器端运行的，并且API调用始终都需要开发人员凭据才能做出成功响应。这是因为API调用是AWS SigV4签名的API调用。

此外，两个API调用都支持不同的Auth Flow，如下所示。

InitiateAuth支持以下验证流程：

USER_SRP_AUTH
REFRESH_TOKEN_AUTH
USER_PASSWORD_AUTH
CUSTOM_AUTH

请注意，AWS CLI文档[a]当前指出ADMIN_NO_SRP_AUTH是可能的值。但是，我已经对API调用进行了测试，并且可以确认CLI的文档当前不正确。

AdminInitiateAuth支持以下身份验证流：

USER_SRP_AUTH
REFRESH_TOKEN_AUTH
CUSTOM_AUTH
ADMIN_NO_SRP_AUTH
USER_PASSWORD_AUTH

InitiateAuth的用例示例：如果您希望用户向Web应用程序进行身份验证。

AdminInitiateAuth的用例示例：需要基于特定AWS凭证进行服务器端身份验证或访问以筛选仅特定IAM用户可以使用Cognito进行身份验证的任何用例。

如先前george所述，InitiateAuth对于您的用例来说是理想的，因为您的应用程序是客户端应用程序。另外，如果您担心安全性，可以将USER_SRP_AUTH与InitiateAuth一起使用。有关在生产代码中使用USER_SRP_AUTH流的更多信息，请参考以下NPM文档[b]。

参考

[a]。 https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/initiate-auth.html

[b]。 https://www.npmjs.com/package/cognito-srp

Answer 2

initiateAuth和adminInitiateAuth做类似的事情，但是它们具有不同的用例和流程。

当您拥有最终用户客户端应用程序时，将使用

initiateAuth。用户输入其凭据，并通过安全远程密码协议发送它们。如果流程成功，则最终用户将获得令牌并被允许访问。 Android，IOS和Javascript SDK使用此流程，因为它与客户端有关。

adminInitiateAuth用于没有客户端用户应用程序但具有使用Java，Python或某些其他后端语言的安全后端应用程序的情况。此方法不不接受用户名和密码用户凭证进行管理员登录，但需要AWS凭证。

在您的情况下，如果您有客户端应用程序---> Cognito并直接使用例如Android SDK或Javascript SDK，则应在SDK中使用initiateAuth传递用户凭据。但是，浏览器->后端-> Cognito意味着您拥有专用的后端，因此在这种情况下，您应该使用adminInitiateAuth。更多信息here

Answer 3

我也花了很多时间研究关于以下主题的稀有文档何时使用AdminInitiateAuth与InitiateAuth。

https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html应该会有所帮助，但我发现它的结构不好且非常混乱。

根据我的理解，您是对的，您可以在服务器上同时使用两种方法：

InitiateAuth和AuthFlow=USER_PASSWORD_AUTH（要求使用客户端密钥创建的应用客户端）。
AdminInitiateAuth与AuthFlow=ADMIN_USER_PASSWORD_AUTH（已替换的旧版ADMIN_NO_SRP_AUTH）

我相信第二种选择对于服务器使用情况更有意义。这样，您可以在应用客户端设置中完全禁用ALLOW_USER_PASSWORD_AUTH身份验证流。虽然可能不是很大的风险，但由于不需要InitiateAuth API，所以感觉很干净，因为这不是必需的。

Answer 4

AdminInitiateAuth 仅存在一个原因：这样您就可以避免服务器端代码中 SRP 的麻烦，同时仍然需要客户端代码使用 SRP。

SRP 更安全，但实施起来烦人/不方便。此外，如果您正在编写在服务器上运行的代码，那么 SRP 提供的许多好处无论如何都是无关紧要的（您的代码在安全、受保护的环境中运行）。

如果您像这样设置 Cognito 应用客户端：

[X] ALLOW_USER_SRP_AUTH
[ ] ALLOW_USER_PASSWORD_AUTH
[X] ALLOW_ADMIN_USER_PASSWORD_AUTH

... 那么任何不受信任/公共客户端代码必须使用 SRP，但受信任服务器端代码可以自由使用普通的旧用户/密码流。（当然服务器端代码必须有AWS凭证才能享受这个特权）

尽管两者在功能上几乎相同，但存在一些表面差异，但您绝对明白。

AWS Cognito-AdminInitiateAuth与InitiateAuth

4 个答案:

参考