AWS Cognito - AdminInitiateAuth 与 InitiateAuth

Question

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

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

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

发起身份验证：

  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 调用都支持不同的身份验证流程，如下所述。

InitiateAuth支持以下身份验证流程：

• USER_SRP_AUTH
• REFRESH_TOKEN_AUTH
• USER_PASSWORD_AUTH
• 自定义授权

请注意，AWS CLI 文档 [a] 目前指出 ADMIN_NO_SRP_AUTH 是一个可能的值。 但是，我已经在我这边测试了 API 调用，我可以确认 CLI 的文档当前是不正确的。

更新（12/09/2019）：看起来在写完这个答案后，Amazon Web Services 已将其文档更新为正确的可能值。 该文档现在说明如下：

ADMIN_NO_SRP_AUTH is not a valid value.

AdminInitiateAuth支持以下身份验证流程：

• USER_SRP_AUTH
• REFRESH_TOKEN_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]。

参考

[一种]。 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 使用，因为它与客户端有关。

当您没有客户端用户应用程序，而是使用 Java、Python 或其他后端语言的安全后端应用程序时，将使用 adminInitiateAuth。 此方法不接受用于管理员登录的用户名和密码用户凭证，但需要 AWS 凭证。

在您的情况下，如果您有一个客户端应用程序 ---> Cognito 并直接使用例如 Android SDK 或 Javascript SDK，那么您应该在传递用户凭据的 SDK 中使用 initiateAuth。 但是，浏览器 --> 后端 --> Cognito 意味着你有一个专用的后端，所以在你的情况下你应该 adminInitiateAuth。 更多信息在这里

Answer 3

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

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

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

[X] ALLOW_USER_SRP_AUTH
[ ] ALLOW_USER_PASSWORD_AUTH
[X] ALLOW_ADMIN_USER_PASSWORD_AUTH

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

尽管两者在功能上几乎相同，但存在一些表面差异，但您绝对会发现这一点。

Answer 4

我也花了很多时间研究关于何时使用 AdminInitiateAuth 与 InitiateAuth 的稀缺文档。

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

据我了解，你是对的，你可以在服务器上使用这两种方法：

1. InitiateAuth with AuthFlow=USER_PASSWORD_AUTH （需要使用客户端密码创建应用程序客户端）。
2. AdminInitiateAuth with AuthFlow=ADMIN_USER_PASSWORD_AUTH （替换旧版ADMIN_NO_SRP_AUTH ）

不过，我相信第二个选项对于服务器使用场景更有意义。 这样您就可以在应用程序客户端设置中完全禁用ALLOW_USER_PASSWORD_AUTH身份验证流程。 虽然可能不是很大的风险，但不向公众开放InitiateAuth API 感觉更干净，因为它不是必需的。