微服务架构下 JWT 公钥缓存优化的核心是在网关或资源服务本地缓存 JWKS 端点返回的公钥集，缓存有效期（TTL）需短于认证服务的密钥轮换周期。适用场景为高频 token 验证场景，风险边界在于缓存过期前密钥轮换会导致验证失败。
先说结论：本地缓存 JWKS 是标准做法，关键在于 TTL 配置与密钥轮换策略对齐，避免使用硬编码公钥。
- 适合：高并发 token 验证、认证服务与资源服务网络隔离场景
- 先准备：确认认证服务 JWKS 端点地址及密钥轮换周期
- 验收：验证缓存失效后能否自动刷新公钥且不影响业务
快速配置思路
主流开发框架的安全库通常内置 JWKS 缓存配置，无需自行实现缓存逻辑，直接调整 TTL 参数即可。
// Spring Security OAuth2 Resource Server 配置示例
spring:
security:
oauth2:
resourceserver:
jwt:
jwk-set-uri: https://auth.example.com/.well-known/jwks.json
# 部分版本支持通过 HttpClient 配置缓存，或需自定义 JwtDecoder
// Node.js jsonwebtoken + jwks-rsa 配置示例
const jwksClient = require('jwks-rsa');
const client = jwksClient({
jwksUri: 'https://auth.example.com/.well-known/jwks.json',
cache: true, // 启用缓存
cacheMaxAge: 600000, // 缓存时长 10 分钟（需小于轮换周期）
rateLimit: true
});
为什么会这样
缓存 JWT 公钥是为了减少每次请求验证签名时向认证服务发起的网络开销。每次验证 JWT 签名都需要公钥，如果每次请求都远程获取 JWKS，会增加验证延迟并给认证服务带来不必要的负载。公开资料中没有看到可靠的量化数据表明具体延迟降低多少，但工程共识是本地缓存能显著减少网络往返。
分步处理
第一步是确认当前使用的 JWT 验证库是否支持 JWKS 自动缓存，Spring Security、Auth0 SDK、AWS Cognito SDK 等主流库均支持。
第二步是配置缓存 TTL，取值应小于认证服务密钥轮换间隔，例如密钥每天轮换，缓存 TTL 建议设置为 1 小时至 6 小时之间。
第三步是配置缓存失效策略，确保缓存过期后库能自动重新请求 JWKS 端点，而不是直接报错。
第四步是监控 JWKS 请求频率，如果频率异常高，说明缓存未生效或 TTL 设置过短。
怎么验证是否生效
查看应用日志或认证库的调试日志，确认 JWKS 请求不是每次鉴权都发生，而是间隔性发生。
使用压测工具模拟高并发请求，观察认证服务端的 JWKS 端点 QPS，开启缓存后该端点请求量应大幅下降。
手动触发密钥轮换（在测试环境），观察资源服务在缓存过期后是否能自动获取新公钥并验证通过，无需重启服务。
常见坑
缓存 TTL 设置大于密钥轮换周期，会导致密钥轮换后旧缓存仍生效，新 token 验证失败。
部分旧版本库不支持自动刷新缓存，缓存过期后可能抛出异常，需要升级库版本或自定义 JwtDecoder。
不要在代码中硬编码公钥字符串，硬编码会导致密钥无法轮换，失去安全性。
网关层缓存与服务层缓存重复配置，可能导致缓存层级混乱，建议在网关层统一收敛鉴权逻辑。
常见问题
JWT 公钥缓存 TTL 设置多少合适？
缓存 TTL 必须短于认证服务的密钥轮换周期，通常建议设置为轮换周期的 50% 至 80%。
密钥轮换期间如何避免验证失败？
认证服务应同时保留新旧公钥一段时间，资源服务缓存过期后拉取到新公钥即可无缝过渡。
本地缓存公钥会有安全风险吗？
公钥本身是公开信息，缓存公钥没有泄露风险，风险在于缓存过期未及时更新导致拒绝服务。
参考来源
- IETF RFC 7517: JSON Web Key (JWK), https://datatracker.ietf.org/doc/html/rfc7517
- Spring Security OAuth2 Resource Server Documentation, https://spring.io/projects/spring-security
- Auth0 JWKS Caching Best Practices, https://auth0.com/docs