SpringBoot启动阶段如何预缓存JWT校验所需Okta公钥

当前基于Java类库实现JWT令牌校验时，原本计划通过注册Bean的方式缓存公钥，但耗时统计显示：仅调用AccessTokenVerifier类的decode方法时，才会触发内部公钥缓存逻辑。
SpringBoot应用采用多Pod部署模式，decode方法只有接收到携带令牌的请求才会执行，这种懒加载逻辑会带来额外性能开销：如果集群共部署n个Pod，前n次命中不同Pod的业务API调用，都会触发Okta内部请求公钥端点拉取公钥、完成缓存的操作。
需求为实现应用启动阶段就完成公钥缓存，消除首次请求的额外开销。
相关配置参考：

方案1：启动阶段主动触发公钥加载（无侵入，改造成本最低） #

利用SpringBoot提供的启动扩展点，在应用初始化完成、接收业务流量前主动触发公钥拉取逻辑，不需要修改原有JWT校验配置。
直接新增一个启动执行类即可，示例代码：

import com.okta.jwt.AccessTokenVerifier;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;

@Component
public class JwkPreLoadRunner implements ApplicationRunner {

    private final AccessTokenVerifier tokenVerifier;

    // 注入项目中已经配置好的AccessTokenVerifier Bean
    public JwkPreLoadRunner(AccessTokenVerifier tokenVerifier) {
        this.tokenVerifier = tokenVerifier;
    }

    @Override
    public void run(ApplicationArguments args) {
        // 主动触发公钥拉取逻辑，不需要传入合法令牌
        try {
            tokenVerifier.decode("preload_trigger_token");
        } catch (Exception e) {
            // 传入无效令牌必然抛校验异常，直接忽略即可，此时公钥已经完成拉取缓存
        }
    }
}

每个Pod启动时都会自动执行该逻辑，提前完成公钥拉取缓存，不会把拉取公钥的开销转嫁给首次业务请求。

方案2：自定义Verifier构造逻辑，显式预加载公钥（可控性最高） #

如果不想用传入无效令牌的方式，可以手动控制公钥加载流程，构造AccessTokenVerifier实例时就把提前拉取好的公钥注入进去，从根源避免懒加载：

• 在AccessTokenVerifier的Bean初始化逻辑中，先通过HTTP客户端主动请求Okta的JWK端点（地址格式为https://{你的Okta域名}/oauth2/default/v1/keys），拿到全量公钥集合
• 将拉取到的公钥集合绑定到Verifier的密钥解析器中，再返回实例化完成的Verifier Bean
• 可以根据业务需求自定义公钥的定时刷新逻辑，灵活度比默认实现更高

方案3：配合容器编排就绪探针（无代码改造） #

如果使用K8s等容器编排平台部署，可以配置就绪检测规则：只有公钥缓存完成后，Pod才会被标记为就绪状态、挂载到Service后端接收流量。该方案一般和方案1配合使用，避免启动未完成的Pod接收请求。

注意：公钥存在定期轮换机制，预加载仅解决首次请求的性能问题，不要关闭Okta默认的公钥自动刷新逻辑，避免公钥轮换后出现令牌校验失败的问题。

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