好的，我正在使用 AWS Cognito 设置用户登录/注册。用户登录后，我想授予他们调用我使用 API 网关构建的 API 的权限。
我已经设置了 Cognito 用户池、Api（具有 Cognito 用户池授权）和 lambda 函数。我现在尝试通过传递测试用户用户名和密码来登录 Web 应用程序。目前这确实有效，我从 cognito 取回了访问令牌、id 令牌和刷新令牌。我还能够通过将带有授权标头的 ID 令牌传递到 API 网关来调用 API。我暂时不尝试实现 MFA，因此我正在执行的对 AWS SDK 的唯一方法调用是
InitiateAuthCommand我现在的问题是，我该如何处理这些代币？我是否应该将它们存储在本地存储中，以便应用程序可以访问它们以进行路由保护，并在它们过期时将用户从应用程序中注销？这是我第一次做这样的事情，我想把它做好。
到目前为止，AWS 文档在设置方面提供了很大帮助，但除了让您的应用程序处理它们之外，它们并没有真正说明您应该如何处理从 Cognito 传回的令牌。显然，除了让用户能够调用我构建的这个 API 之外，如果从 cognito 传回令牌，我还想让用户登录到应用程序，所以我想我必须将它们存储在本地存储中或某种状态变量，然后应用一些逻辑来过期/刷新它们并让用户访问特定的路由？
有人可以解释一下这一点吗？我觉得我已经走了很远，但我需要一些额外的帮助来理解这一点以克服困难。
身份验证流程 -> 用户访问登录/注册页面 -> 用户输入用户名和密码 -> cognito 令牌传回客户端 -> ID 令牌传递到 API 网关调用的授权标头以让用户到达端点。
编辑：在验证令牌后，我将它们放置在状态变量中。这可行，但我真的不知道这是否是存储它们的正确方法
您在实现登录和令牌检索的后端设置方面做得非常出色。根据您的描述，您主要担心两个问题：
1- 如何存储 Cognito 令牌？
在 Web 应用程序中存储用户令牌可以被视为完全另一个主题。但有两种流行的好做法：
本地存储：您可以将令牌存储在浏览器的本地存储中。这是一种常见做法，但请注意，它可能会使令牌遭受跨站点脚本 (XSS) 攻击。如果采取其他措施，这是一个可行的方法。例如，AWS Amplify 的 Javascript SDK 默认使用本地存储来存储认知令牌。
会话存储：这与本地存储类似，但在会话结束（即浏览器关闭）时被清除。如果您希望令牌仅在活动会话期间持续存在，这可能是一个更安全的选项。
状态变量（内存存储）：将令牌存储在 JavaScript 变量（内存存储）中意味着刷新页面时令牌会丢失，这在用户体验方面不太实用，并且可能需要您非常频繁的令牌检索 api 调用。
如果您希望跨浏览器会话保持持久性，您可以简单地选择本地存储；如果不担心的话，也可以选择会话存储。
2- 代币过期了怎么办？
处理令牌过期通常涉及使用刷新令牌。就您而言，AWS SDK 可以促进这一点。
一种常见的策略是，如果当前令牌已过期，则在进行 API 调用时刷新 ID 令牌。通过检测过期的令牌响应、刷新令牌，然后重试初始 API 调用来实现此目的。
关于用户注销，令牌过期后立即注销用户并不是标准做法。许多 Web 应用程序允许用户在短时间内不活动时保持登录状态（考虑到 JWT 的生命周期通常很短）。在大多数情况下，您甚至可能不想注销用户，除非用户明确请求。如果您想在没有用户命令的情况下实现立即注销，这通常涉及基于用户操作、时间间隔、设备类型等的额外逻辑。为简单起见，您可以选择稍后根据您的具体要求解决此问题。