为什么验证Amazon Cognito签发的JWT不需要私钥？

你的顾虑本质是对非对称加密签名流程的使用逻辑存在误解，核心逻辑梳理如下：

• 非对称签名算法（Cognito默认使用RS256）的签名、验签操作是完全分离的：仅持有私钥的主体（也就是Amazon Cognito服务本身）可以生成合法签名，公开可获取的公钥仅具备验签能力，没有办法用来生成有效的JWT签名。
• 攻击者篡改JWT的尝试不可能通过验签：如果攻击者修改了JWT的Header或Payload内容，没有Cognito托管的私钥的前提下，根本无法生成和篡改后内容匹配的合法签名。即便攻击者拿到了公开的公钥，也无法反向推导私钥，更无法用公钥生成合法签名，API侧用公钥验签时会直接识别出签名和内容不匹配，拒绝请求。
• Cognito的密钥安全机制：每个Cognito用户池都会生成独立的非对称密钥对，私钥全程由AWS托管不对外暴露，公钥通过用户池的JWKS端点公开，所有信任方都可以用这个公钥完成验签，不会带来安全风险。

标准RS256 JWT验签流程：

1. 将JWT的Header、Payload部分用.拼接，得到待验证的原始内容
2. 用公钥解密JWT附带的签名，得到Cognito签名时生成的原始哈希值
3. 自行对步骤1得到的原始内容做相同算法的哈希运算，和步骤2得到的哈希值对比，一致则证明JWT未被篡改、确实由Cognito签发

日常使用时只要做好两点即可规避极少数边缘风险：

• 验签时强制指定签名算法为RS256，禁止接受HS256算法签名的JWT，避免出现算法切换漏洞
• 不要硬编码Cognito公钥，定期从对应用户池的JWKS端点同步最新公钥，适配AWS的自动密钥轮换机制

内容的提问来源于stack exchange，提问作者Christina Stebbins