AWS Cognito Identity Service Provider 似乎将访问令牌存储在本地存储中。这安全吗？

Question

我们正在开发一个应用程序，该应用程序使用通过 Amplify 托管在 AWS 上的 React 前端网站。它与在 EC2 / Elastic Beanstalk 上运行的 .NET Core 3.1 Web API 进行通信。Cognito 用于通过配置为使用 JWT 令牌的 Web API 进行用户身份验证。

它工作正常，但我们注意到 Cognito 提供商将 JWT 访问令牌存储在浏览器本地存储中。这是我们在 Chrome 中使用 F12 并检查本地存储所看到的。

根据我们的了解，不建议将访问令牌存储在本地存储中，因为这会使应用程序容易受到 XSS 攻击。奇怪的是，Cognito 身份提供商选择在这里存储敏感信息。

如果这种方法被认为不安全，那么提供商是否可以配置为将该信息存储在其他地方，例如 cookie？

或者，当我们同时控制前端和后端时，是否有其他方法可以用来保护不涉及令牌的API？显然，API 需要知道哪个用户登录到 Web 应用程序才能执行授权检查。[注意应用程序中的授权是记录级别并在数据库表中定义，因此它超出了简单的用户配置文件属性。]

非常感谢您的建议。

道格

Answer 1

安全性是一个范围而不是一个功能，因此它实际上取决于您对风险与努力的偏好。Amplify 并不是一个特别好的代码库，它有 500 多个问题，如果您查看代码，您可能会对它的质量感到相当震惊。

如果您使用 Hosted-UI，那么您可以自己编写代码来管理令牌，而不是使用 amplify，尽管您需要了解一些有关 OAuth 授权和 OIDC 的知识。

请注意，托管 UI 缺乏大量功能，因此，如果您打算使用它，请确保您对此感到满意。从我的头顶上掉下来

• 托管 UI 中没有静默刷新功能，因此没有安全的方法来存储刷新令牌。
• 托管 UI 中不支持自定义身份验证流程
• 托管 UI 中不支持无密码
• 无法在托管 UI 中预填充字段（例如用户名）
• 无法在自定义 UI 中自定义大量晦涩的错误消息
• 现已修复，但多年来电子邮件地址区分大小写！

另一种方法是使用 AWS SDK 直接使用 cognito-idp 获取令牌，但这也存在很多问题：

• 没有代码/PKCE/随机数功能，因此在移动身份验证会话中不安全
• 无法设置 oauth 范围，因此无法使用它们
• 因此无法用于 OIDC
• SRP 的实施很糟糕，到目前为止还没有达到规范
• 如果您强制进行设备注册，它将在设备注册之前提供工作访问令牌！（允许隐形设备进行恶意登录）

我们使用的是领先的 auth0，但由于 SMS OTP 成本（auth0 每年至少 25,000 美元），我们不得不转向 Cognito。

我已经使用 AWS 十多年了，Cognito 是迄今为止我使用过的最糟糕的服务，而且我已经使用了很多！如果你能避免它，那就这样做。

要回答原来的问题，是的，这是不安全的。你能做的最好的事情就是把它们留在记忆中。如果您愿意，您可以将托管 UI 放在云端后面，并使用 lambda@edge 将令牌转换为 cookie。但这现在让您面临 CSRF 攻击。