nimbus-jose-jwt中DefaultJWKSetCache的lifespan与refreshTime区别是什么

核心行为区别 #

你对两个参数的理解有部分是对的，但核心差异在于「过期后是否影响当前业务」以及「拉取新密钥的触发时机」：

• lifespan 是硬过期阈值
  到达设置时长后，缓存的JWK Set会被直接驱逐失效。下次业务请求需要使用密钥（比如JWT验签）时，必须同步阻塞等待从远程地址拉取最新的JWK Set，拉取失败会直接抛出异常，业务流程会受影响。如果设置为负值，缓存永远不会被主动驱逐。
• refreshTime 是软过期阈值（要求必须小于等于lifespan）
  到达设置时长后，缓存的JWK Set依然有效，当前业务请求可以正常使用旧密钥完成处理，不会阻塞也不会报错。只是会触发后台异步任务去远程拉取最新的JWK Set，拉取成功后直接替换缓存中的旧集合，拉取失败则继续使用旧集合，全程对业务无感知。如果设置为负值，不会触发异步刷新逻辑。

实际场景举例 #

假设配置为 lifespan=24小时，refreshTime=1小时，使用RemoteJWKSet从远程拉取密钥：

1. 服务启动后第一次收到验签请求，从远程拉取JWK Set存入缓存，正常处理请求
2. 第1小时到第24小时之间，每次到达refreshTime阈值后，只要有新的验签请求进来，就会触发后台异步拉取最新密钥：拉取成功就更新缓存，拉取失败就继续用旧的，完全不影响当前请求的处理
3. 如果连续24小时都没能成功拉取到新的JWK Set（比如远程JWKS服务故障），此时lifespan到期，缓存被清空，下一次验签请求必须同步等待远程拉取，拉取失败就会直接返回验签错误

补充问题解答 #

将lifespan设为永不过期（负值）、refreshTime设为1小时，可以实现每小时尝试更新密钥，但无法100%保证一定会更新：

• refreshTime到期不会主动触发刷新，必须有至少一次业务请求用到密钥时，才会触发后台异步刷新逻辑，如果你的服务连续1小时没有收到任何需要用到JWK的请求，就不会触发刷新
• 如果异步拉取远程JWKS接口失败，刷新逻辑会放弃本次更新，继续使用旧的密钥，直到下次有请求触发新的刷新尝试

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