我正在查看网站的 javascript 文件以找到我想要的端点，在此期间我发现了这样的一行。
DASHBOARD_API_Token=eyJraWQiOiJVS2paTnB3SWdBK292QzB3RWdxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx当我解码上述 JWT 时，我发现了像孩子、用户名、用户邮箱、iss = http://cognito-idp.us-east-1.amazonaws.com/ {pool-id}这样的实体
我已经阅读了一些亚马逊资源，这些资源表明可以使用上述令牌获取 aws 凭据。鉴于我只有 jwt 令牌，有什么可能，我是否必须联系网站来撤销当前的令牌？
好吧，就其 JWT 令牌以及您可以使用它们做什么而言，AWS Cognito 是一个非常有趣的野兽。
首先，当您根据 Cognito 用户池对用户进行身份验证时，您会获得 3 个不同的令牌：AccessToken、IdToken和RefreshToken。两者AccessToken和IdToken仅在 1 小时内有效（您无法更改）。这就是你得到 的原因RefreshToken，你可以使用它来获取新的一对，AccessToken并IdToken通过调用，例如，InitiateAuth。RefreshToken默认情况下有效期为 30 天，但您可以在 Cognito 用户池的设置中更改它。
这是 Cognito 提供的最强大的令牌。如果您拥有有效的AccessToken，则可以调用几个非常敏感的 Cognito API。
一个非常令人惊讶的例子是，您可以通过提供来调用DeleteUser API，AccessToken它将完全从 Cognito 用户池中删除您的帐户。这里“最好”的一点是，如果你有一个有效的AccessToken. AWS 开发人员说这是“设计使然”。这是我们决定不将 Cognito 访问令牌传递到应用程序前端的最重要原因之一。
说到 的有效负载AccessToken，唯一可能敏感的声明是client_id，其中包含用于对用户进行身份验证的 Cognito 客户端 ID。如果这个客户端没有客户端密码（这可能首先应该被认为是一个安全漏洞），那么它client_id可以用来调用相当广泛的 Cognito API。但是，Cognito 认为client_id是公共信息。所有其他声明都被视为公开声明，您可以在此处查看声明的完整列表。
包含有关播放器的信息。它可能包含有关玩家的一些个人信息，具体取决于您在 Cognito 用户池中配置的标准声明和自定义属性，但是也可以使用Pre Token Generation Lambda Trigger来禁止或覆盖这些声明。使用此触发器可以隐藏或屏蔽玩家属性，这些属性被认为是敏感的，不应出现在IdToken.
据我所知，您不能用户IdToken调用 Cognito API。
只能用于请求 newAccessToken和IdToken，不能用于调用 Cognito API。在我们的特定用例中，我们必须避免传递RefreshToken到应用程序前端，因为它可用于AccessToken对抗公共 Cognito API（这意味着我们无法阻止用户这样做）。
这只有在 Cognito 用户池已与 Cognito 身份池显式集成（假设应用程序开发人员知道他们在做什么）的情况下才有可能。当您交换 Cognito JWT 令牌时，您会获得临时 AWS 凭证，其权限绑定到在 Cognito 身份池中配置的特定 IAM 角色。这是完全合法的流程和预期的行为。此外，如果 Cognito 身份池配置为允许未经身份验证的访问，您甚至可以在没有 Cognito JWT 令牌的情况下获得临时 AWS 凭证（但这些凭证将绑定到另一个可能更具限制性的 IAM 角色）。
AWS API Gateway 资源可以与 Cognito 用户池集成。根据集成的完成方式，您可以使用集成的 Cognito 用户池AccessToken或IdToken来自集成的 Cognito 用户池。
您可以通过调用GlobalSignOut API 并提供有效的AccessToken. 由于此 API 是公开的，如果您拥有有效的AccessToken.