Apache APISIX OpenID Connect插件与Keycloak集成中的双重请求问题解析

背景介绍

在企业级API网关Apache APISIX与Keycloak身份认证服务的集成实践中，开发人员经常会配置OpenID Connect插件来实现OAuth2.0的令牌自省(introspection)功能。近期有用户反馈在APISIX 3.9.1版本中，当配置了令牌自省功能后，Keycloak服务端会收到重复的请求。

问题现象分析

通过用户提供的配置信息可以看到，这是一个典型的Bearer Token验证场景：

• 配置了introspection_endpoint指向Keycloak的自省端点
• 使用client_secret_basic认证方式
• 启用了bearer_only模式

用户观察到Keycloak服务日志中，对于每个API请求都会记录两次自省请求，这引发了是否正常行为的疑问。

技术原理剖析

在OAuth2.0的令牌自省机制中，APISIX网关需要将客户端携带的访问令牌发送到授权服务器(Keycloak)进行验证。实际上，这种"双重请求"现象是设计使然：

1. 缓存机制：APISIX会对自省结果进行缓存以避免频繁请求授权服务器
2. 缓存刷新：默认情况下系统会定期重新验证令牌以确保其有效性
3. 性能优化：首次请求触发完整验证，后续请求可能仅检查缓存状态

解决方案建议

对于希望优化此行为的用户，可以通过以下配置参数进行调整：

"openid-connect": {
    "introspection_interval": 300,
    "introspection_cache_ignore": false
}

其中：

• introspection_interval：控制缓存刷新间隔(秒)
• introspection_cache_ignore：设为true可禁用缓存(不推荐)

最佳实践

1. 生产环境中建议保持适当的缓存间隔(如300秒)
2. 监控Keycloak的请求负载，根据实际情况调整参数
3. 考虑使用JWKS验证方式替代自省，对简单场景可能更高效
4. 确保网络延迟不会成为性能瓶颈

总结

APISIX与Keycloak集成时出现的双重请求现象是系统的正常行为，体现了安全性与性能的平衡设计。通过合理配置缓存参数，开发人员可以在安全验证和系统性能之间取得最佳平衡。对于高并发场景，建议进行充分的压力测试以确定最优配置。