Spring OAuth2Login()分布式安全会话疑问：Spring Security 5.2+Keycloak架构下是否需部署分布式会话管理器

咱们先把你当前的模式掰明白：你用的OAuth2Login()是基于会话的认证模式，和你之前理解的JWT无状态模式本质上是两回事，这也是为什么会有要不要分布式会话的困惑。

先拆解你当前的认证流程 #

当你启用OAuth2Login()后，整个逻辑是这样的：

1. Angular用户访问受保护的后端接口，会被重定向到Keycloak完成登录
2. 登录成功后，Keycloak给后端返回授权码，后端用授权码换取令牌，再调用UserInfo Endpoint拿到用户基础信息
3. 后端会把这些用户认证信息存在本地HttpSession里，然后给前端返回一个会话Cookie（比如默认的JSESSIONID）
4. 后续前端的所有请求，只要带上这个Cookie，后端就能通过会话ID找到对应的用户信息，所以确实不用前端操心JWT令牌的获取、存储和携带，这也是这个模式便捷的核心原因

分布式部署下必须用分布式会话管理器吗？ #

答案是必须。
如果你的后端是多实例部署（比如用K8s起了多个Pod，或者多台服务器集群），用户的请求可能随机打到不同的后端实例上。而每个实例的本地会话是完全独立的——比如用户第一次请求打到实例A，会话存在A的内存里；下一次请求打到实例B，B上没有这个会话记录，就会判定用户未认证，要求重新登录。

所以这种基于会话的认证模式下，必须用Redis、Spring Session这类分布式会话方案，把会话数据存在共享存储中，让所有后端实例都能访问到同一个会话信息，才能保证用户在分布式环境下的认证状态一致。

为什么你之前以为OAuth2+JWT不用会话？ #

这是因为你混淆了OAuth2的两种典型使用模式：

• 模式一：OAuth2Login（会话式）：就是你现在用的，后端作为OAuth2客户端，负责维护用户会话，前端靠Cookie维持认证状态。适合前后端耦合度较高的场景（比如同域部署），优点是前端完全不用处理令牌相关逻辑，后端还能利用会话的CSRF保护、会话超时管控、便捷注销等特性。
• 模式二：资源服务器+JWT（无状态）：这种模式下，前端直接作为OAuth2客户端和Keycloak交互，拿到JWT令牌后，每次请求后端资源服务器都把令牌放在Authorization: Bearer请求头里。后端只需要验证令牌本身的有效性，不用维护任何会话，是无状态架构，所以分布式部署下不需要会话管理器。但缺点是前端要自己处理令牌的获取、刷新、存储（比如存在localStorage或sessionStorage），还要处理令牌过期、跨域等问题。

给你的选择建议 #

如果你想继续享受当前前端不用管令牌的便捷性，那就在分布式部署时加上Redis这类分布式会话组件，配置Spring Session来实现会话共享；如果想做无状态架构、摆脱会话依赖，那就要调整架构：让Angular作为OAuth2客户端直接对接Keycloak获取JWT，后端改成资源服务器模式（配置oauth2ResourceServer().jwt()）。

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