Cognito 用户池 ID 和客户端 ID 是否敏感？答案

【问题标题】：Are the Cognito User pool id and Client Id sensitive?Cognito 用户池 ID 和客户端 ID 是否敏感？
【发布时间】：2020-12-03 19:17:23
【问题描述】：

有谁知道 User Pool Id 和 Client Id 是否敏感？目前我让他们坐在前端，只是想知道这是否危险。如果是，如何利用它们？

【问题讨论】：

标签： amazon-web-services aws-cognito

【解决方案1】：

不，他们不是。他们应该是公开的。可以利用它们的唯一方法是有人可以使用它们对您的用户池进行大量注册调用。但只要这些注册没有经过验证，它们就不会被转换为活跃用户（除非您启用了用户的自动验证）。这不是 AWS 特定的问题。假注册是一件很头疼的事，即使没有使用 SignUp api 并且使用 PHP 后端进行注册，也会面临这个问题。面对这种情况的唯一方法是电子邮件/电话验证。

当然，如果您在用户池中禁用了注册，即只有管理员可以创建用户，那么这根本不是问题。

【讨论】：

谢谢@agent420。情况似乎确实如此。我必须说，虽然这感觉有点漏。例如，这意味着任何人都可以劫持您的 cognito 帐户并使用它在他们的应用程序中注册和验证他们的用户。 ://
文档还指出：您有责任保护任何应用程序客户端 ID 或机密，以便只有授权的客户端应用程序才能调用这些未经身份验证的 API，这也令人困惑。 docs.aws.amazon.com/cognito/latest/developerguide/…
是的，好像是这样。我听说过类似的查询。但是每个人都担心 DDoS 攻击和虚假注册。从来没想过，但是是的，这些详细信息可用于在另一个应用程序中启用身份验证和注册。但是想一想 - 如果您开发了一项服务，您是否会将用户的命运交给其他人，因为 userpool 的所有者可以随时删除它。而且看到 cognito 是多么便宜，我认为没有人会冒险。
此外，如果您真的想隐藏客户端ID，您可以使用带有应用集成功能的内置UI。这样，redirect_uri 需要在用户池中设置，其他域将无法通过内置 UI 使用您的用户池
从来没有使用过内置的 UI。但这听起来可能是一个不错的选择。某人使用您的服务的例子实际上只是为了展示某人如何很容易地做他们绝对不应该被授权做的事情。我同意这样做可能没有什么动机，但原则适用。

【解决方案2】：

Cognito 生成的ID token 和Access token 同时包含用户池 ID 和客户端 ID，这些值不可能被设计为私有的。

【讨论】：

【解决方案3】：

这些信息不敏感，但如果一起使用，它们可以允许客户端在您的 cognito 用户投票中创建用户，因此可以访问您的应用程序。

对管理方法的请求需要“userPoolId”，它应该保存在您的后端。 Client/Normal 请求通常使用“clientId”，在同一个用户池下可以有多个。

总之，“userPoolId”是您的敏感信息，不应在您的客户端中公开。

注意：Amplify.@auth 需要 userPoolId 和 clientId，这是他们的另一个安全故障，但是我没有看到他们在任何请求中公开 clientId。让我们希望他们尽快解决这个问题。

【讨论】：

我不认为暴露这些有什么害处。甚至 AWS Amplify 也将 aws-exports.js 文件存储在客户端，其中包含所有这些值，包括您的 dyanmodb 表名称、api 路径、s3 存储桶名称等
无论如何，如果您的应用具有注册功能，用户无论如何都可以在用户池中创建他们的用户帐户