我一直在研究在经过身份验证的Quarkus应用程序中跨pod同步OIDC认证状态。这是为了消除粘滞会话的需要，并在请求在服务器周围反弹时保持同步。
当使用quarkus.http.auth.session.encryption-key属性使用标准登录时，有一个解决方案，但从我可以告诉OIDC什么也没有。查看身份验证机制重新身份验证和默认令牌管理器实现，我可以通过跨memcache或DB连接同步一些状态令牌(即刷新令牌和访问令牌)来实现这一点。这可以在令牌状态管理器中生成的idToken值上进行匹配，以保持事情正确排列。
实现的计划是将DTO/表添加到现有的DB连接。我会添加一个高优先级过滤器或验证机制，检查缓存，如果状态没有设置，然后检查db的现有数据。对于验证机制实现，如果不存在状态或cookie，我将退回到default/super。
我是否把这个问题复杂化了，并且有一个包来管理它，或者这是问题的解决方案?任何反馈将不胜感激!
感觉你做了太多的管道，如果你做出正确的设计选择，其中大部分应该是可以避免的。
如果你描述你的应用程序/业务场景，而不是从技术开始，这将会有所帮助，但这里有一些一般原则。
<<p>认证状态/strong>这通常由授权服务器(AS)管理。AS的多个实例在同一数据库中存储共享状态。AS处理困难的管道，因此您不需要创建自己的令牌存储。
api和客户端
这些在默认情况下只使用jwt，并且非常易于管理。Web客户端是一种特殊情况，可能需要将令牌包装在安全cookie中。
把它们放在一起
请看一下来自security的这些最新资源，我希望它们能演示一个简单的体系结构。
- Docker Compose File将Auth状态存储在postgres数据库中，但您唯一需要做的就是部署security数据库
- Web应用程序+ API的代码非常简单，因为外部化安全
- 文章解释了设计模式和分层
在这个标准的Web/API解决方案中，浏览器在AES256加密的HTTP中使用OIDC令牌，这意味着后端使用无状态的OAuth数据存储，任何类型的后端集群工作都没有问题。
我想通过上面的答案实现的是鼓励简单-如果需要，可以扩展到全球系统。如果有帮助，很乐意回答后续问题。