预获取AWS Cognito JWT密钥本地存储是否存在未考虑的弊端？

直接说你这个方案可能遇到的几个核心问题：

• 密钥突发轮换导致验证失败：AWS Cognito的JWKS密钥并非只会按固定周期轮换，遇到安全事件、密钥提前过期等场景时，会触发紧急轮换。如果你的定时任务仅每日更新，那在轮换后到下次更新的这段时间里，本地缓存的旧密钥无法验证新签名的JWT，会持续抛出无效签名的错误。

• 更新时机的时间差风险：就算是常规密钥轮换，你的每日更新时间和实际轮换时间可能存在时间差。比如你凌晨3点更新了缓存，当天上午10点Cognito完成密钥轮换，剩下的14小时里你的脚本都会用旧密钥，导致这段时间内的新JWT全部验证失败。

• 多实例环境下的一致性问题：如果你的脚本部署在多台服务器或多个容器实例上，每台的定时任务执行时间可能不一致，会出现部分实例用新密钥、部分用旧密钥的情况，导致相同的JWT在不同节点验证结果不同，排查问题时会非常棘手。

• 本地存储的可靠性风险：本地文件存储可能遇到权限问题、磁盘满了、文件被误删/篡改等情况。一旦出现这些问题，脚本要么读取不到密钥，要么读取到错误的密钥，直接导致所有JWT验证失败，而且这种问题排查起来比远程拉取的网络问题更隐蔽。

• 缺少动态 fallback 机制：如果你的脚本只依赖本地缓存，没有在验证失败时自动触发远程拉取最新JWKS的逻辑，那遇到密钥变更时，只能等次日的定时任务更新，这段时间内的业务会持续受影响，没有快速恢复的途径。

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