AWS Cognito用户池ID和应用程序客户端ID是秘密吗？

Question

所以有两个问题。

1. Aws Cognito用户池的UserPoolId和AppClientId是否是机密信息？
2. 如果是，如何保护它们的安全性？我看到的所有库（aws-amplify/amazon-cognito-identity-js）似乎都是完全基于客户端的。

我在这里错过了什么。看起来只需要这两个信息，就可以让任何恶意用户获得 JS 访问Cognito信息的权限。

- Matt Trax

Answer 1

它们并不是秘密。

事实上，ID令牌包含iss声明（属性），它是用户池ID，以及aud声明，它是应用程序客户端ID。

访问令牌包含iss声明，再次是用户池ID，而client_id声明代表应用程序客户端ID。

如果这些令牌中的任何一个被不良分子截获，那么他们可以解码这些令牌，因为它们仅是base64编码（未加密）。

然而，仅仅知道这两个信息通常对于攻击者来说并没有太大用处，只要JWTs被正确验证即可。

它不会给攻击者访问用户池本身的权限，因为那需要AWS凭证，这些凭证只授予已经得到适当认证的用户或身份（然后由ID池发放凭证等）。

就访问API而言，攻击者可能想以某种方式修改有效载荷，以更改请求中的数据。例如，他们可能想将假设的role声明从user变为admin，以升级特权并访问他们不应该访问的区域。这可以通过正确在服务器端验证JWT令牌来减轻，以确保负载未被篡改。

另一种 API 攻击的类型可能是使用一个已经正确验证的令牌来访问另一个 API（JWT 替换）。通过验证 iss 和 aud 声明，以确认 JWT 是否特定地颁发给了预期的 User Pool 和 App Client，可以缓解此问题。

- lemming

---

谢谢，这让我的工作变得更容易了，我对现有的设计感到更加满意。非常清晰易懂的回答！ - Matt Trax

但是如果攻击者使用用户池ID和appClientId设置客户端，恼人地在给定的用户池中创建数千个用户怎么办？这可能会用虚假用户填满用户池... - Bruno Negrão Zica

鉴于机器人和虚假账户的数量，我猜这是Twitter和Facebook都面临的问题。了解他们如何监控将会很有趣。我想知道他们是否使用人工智能来分类账户行为？ - lemming

是的，监控！我发现Cognito向cloudwatch发送“SignUp”事件，而cloudwatch有一个名为“异常检测”的功能，使用人工智能来区分正常使用和非正常使用，从而触发警报。还有“Cloudtrail”，记录客户端API调用Cognito的IP地址。 - Bruno Negrão Zica

我认为公开这些内容没有任何危害。即使 AWS Amplify 也在客户端存储了 aws-exports.js 文件，其中包含所有这些值，包括您的 DynamoDB 表名称、API 路径、S3 存储桶名称等。 - Yusuf

如果您的应用程序完全是无服务器的，您使用Cognito进行身份验证，然后使用经过身份验证的用户会话访问API，中间没有JWT令牌，那么应该采取什么正确的方法？ - DJG22