背景
我一直在开发一个消耗AWS资源（主要是API网关后面的Lambda）的前端JavaScript应用程序。 API 网关资源受 IAM 保护，并且应用程序相应地使用 Cognito 提供的大部分内容。
这包括一个身份池未经身份验证的身份启用，并与 Cognito 用户池和多个社交和自定义 OIDC 提供商联合。使用 Amazon 的 SDK，仅通过我们的前端 JavaScript 代码与 Cognito 进行交互。
未经身份验证的身份
ID 池 id 的敏感性适用于我的所有用例，但我对未经身份验证的用例最好奇。我们一直在关注似乎是亚马逊建议的方法 http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html：使用Cognito或STS获取IAM密钥，并使用这些密钥访问AWS资源。我什至一直在传播这个福音。 https://stackoverflow.com/questions/47125993/authentication-without-user-credentials/47126720#47126720
这一切都很好，但它确实需要我向前端公开我的身份池 ID。身份池 ID 是您为未经身份验证的 IAM 角色获取 IAM 密钥所需的唯一信息。
从理论上讲，任何攻击者都可以使用我使用的相同 Amazon SDK 获取我的身份池 ID 并开始滥用我的资源（Unauth IAM 角色允许的资源）。
问题
- 一般来说，我应该认为身份池 ID 有多敏感？向任何人展示这个就可以了吗？
- 如果我决定的话is足够敏感，不会暴露给浏览器，我该如何处理？我在哪里以及如何隐藏它并获取它？
- 无论如何，我应该“烘焙”一种频繁轮换 ID 的方法吗？
- 是否存在可以公开 id 的（某种类型的）用例，以及不可以公开 id 的用例？
我正在寻找的答案
正如上面链接的答案中所述，我的理解是，未经身份验证的身份并不是万无一失的，并且只提供了一个合理的线路另一端是您的应用程序的置信度。换句话说，虽然不是不可能，但至少是相当困难防止有人使用此模型滥用您的 AWS 后端。
除了上面的要点之外，我很高兴对这种理解提出任何批评。我是否低估了未经身份验证的 IAM 访问 AWS 的安全性？超卖了？
免责声明
我承认这个问题听起来很像this one https://stackoverflow.com/questions/40777433/hard-coding-identity-pool-id-for-aws-cognito-is-dangerous-in-security. I'm not询问在我的应用程序中对身份池 ID 进行硬编码；这已经是从网络服务中获取的。然而，它仍然完全暴露在前端，你可以说它实际上是easier将其从 AJAX 响应中提取出来，而不是从精简代码中提取出来。
我确实尽可能严格地锁定 Unauth 角色，并且我知道允许匿名访问内容只能如此安全。
