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

在实际生产环境中，许多开发者选择使用Apache APISIX作为API网关，并与Keycloak身份认证服务进行集成。本文将深入探讨一个常见现象——当配置OIDC插件进行令牌自省(introspection)时，Keycloak服务端会收到重复请求的技术原理和解决方案。

问题现象

当开发者在APISIX中配置openid-connect插件并启用令牌自省功能时，通过日志观察发现Keycloak服务端会收到两次相同的自省请求。具体配置中启用了以下关键参数：

• bearer_only设置为true
• 配置了正确的introspection_endpoint
• 使用client_secret_basic作为认证方式

技术原理

这种现象实际上是APISIX网关的预期行为，主要源于以下两个技术层面的设计：

1. 缓存机制：APISIX为了提高性能，会对令牌自省结果进行缓存。第一次请求是实际向Keycloak发起的验证请求，第二次请求则是从缓存中获取验证结果。

2. 健康检查：网关在初始化连接时可能会发送测试请求来验证端点可用性，确保后续请求能够正常处理。

优化建议

对于希望优化这一行为的开发者，可以考虑以下配置调整：

1. 调整自省间隔：通过设置introspection_interval参数来控制缓存的有效期，平衡安全性和性能。

2. 监控与调优：合理设置缓存时间需要考虑业务场景的安全要求。对于高安全性场景可以缩短间隔，对性能敏感场景可适当延长。

配置示例

以下是优化后的配置片段参考：

"openid-connect": {
    "introspection_interval": 300,
    "bearer_only": true,
    "introspection_endpoint": "http://keycloak:8080/realms/realms/protocol/openid-connect/token/introspect"
}

总结

理解APISIX与Keycloak集成时的这种双重请求现象，有助于开发者更好地规划和优化系统架构。通过合理配置缓存参数，可以在保证安全性的同时获得最佳的性能表现。对于大多数生产环境，建议保持默认行为并适当调整缓存参数即可满足需求。