事后分析：由 JWKS 缓存和签名密钥轮换引起的认证失败

日期： 2026 年 1 月 8 日（太平洋时间）

时长： 约 60 分钟

影响： 部分生产租户遇到了登录和令牌验证失败的问题；Console 登录可能也会受到影响

摘要#

签名密钥轮换后，*.logto.io 域下缓存的 JWKS 与实际密钥不匹配，导致令牌验证失败。我们清除了 JWKS 缓存并回滚到之前的签名密钥以恢复服务。

部分用户可能因浏览器缓存问题，继续遇到 Console 登录故障。对由此带来的影响我们深表歉意。

时间线（太平洋时间）#

• 下午 4:00 事件开始（认证/令牌验证错误增加）
• 下午 4:35 确定根本原因（JWKS 被缓存且签名密钥已轮换）
• 下午 4:41 清除缓存
• 下午 4:49 回滚签名密钥
• 下午 5:00 服务恢复；持续监控

事件详情#

影响#

在事件期间，部分用户无法登录，部分令牌校验失败。这影响了多个生产租户，也可能阻止访问 Logto Console。

我们没有发现与本次事件相关的未授权访问证据，影响仅限于认证失败。

用户操作#

如果你仍无法登录 Logto Console，请尝试：

• 打开无痕或隐私窗口，或
• 清除/禁用浏览器缓存后重试

事件经过#

1. 我们更新了客户租户域（*.logto.app）的 JWKS 缓存设置。Cloud 域（*.logto.io）的 JWKS 缓存设置未被正确关闭。
2. 我们为 Cloud 服务进行了签名密钥轮换。由于 *.logto.io 的 JWKS 响应已被缓存，一些客户端继续使用过期的 JWKS，无法验证新签发的令牌。
3. 我们清除了 *.logto.io 的 JWKS 缓存，回滚到之前的签名密钥，然后再次清除 JWKS 缓存，以确保客户端能获取回滚后的密钥集。
4. 认证功能恢复。部分用户可能因浏览器缓存仍遇到 Console 登录问题。

经验教训#

密钥轮换不仅仅是密钥管理的任务，它是一个端到端的兼容性变更，必须考虑签发方与验证方之间的缓存行为。不同域（*.logto.app 与 *.logto.io）之间的配置漂移是实际风险。对于一个域安全的变更，如果未同步应用，可能会破坏另一个域。

我们的现有集成测试没有覆盖类似生产环境的 JWKS 缓存行为，因此在密钥轮换前未发现此类失败模式。

预防措施#

我们正在实施：

• 将 JWKS 缓存失效作为签名密钥轮换流程的必要步骤（仅在失效完成后轮换）
• 在失效流程到位前保持 JWKS 缓存关闭，之后为提升性能再重新开启缓存
• 针对密钥轮换加入类似生产环境的集成测试，包括 JWKS 缓存行为和缓存失效检查