为什么Spring Security会话策略设为STATELESS会导致OAuth2登录重定向循环？

你遇到的无限重定向问题，本质是Spring Security OAuth2登录流程的核心组件，和STATELESS会话策略的设计逻辑存在直接冲突。

SessionCreationPolicy.STATELESS的官方约定是：Spring Security全程不会主动创建HttpSession，也不会依赖HttpSession完成任何状态的读取、写入操作。

OAuth2授权码登录的流程天生依赖临时会话存储完成安全校验，在使用默认组件的前提下，开启STATELESS会直接打断两个关键流程节点：

• 授权发起阶段：当系统匹配到/oauth2/authorization/facebook路径，准备引导用户跳转Facebook授权时，OAuth2AuthorizationRequestRedirectFilter会生成带随机state值（用于防CSRF攻击）、PKCE校验参数的完整授权请求，默认通过HttpSessionOAuth2AuthorizationRequestRepository将这些参数存入HttpSession，留作后续回调校验使用。
  开启STATELESS模式后，系统不会创建HttpSession，这部分校验数据会直接丢失。
• 授权回调阶段：当用户完成Facebook授权、携带code和state参数跳回应用回调地址/login/oauth2/code/facebook时，OAuth2LoginAuthenticationFilter需要从存储中取出之前留存的授权请求，对比回调携带的state值是否匹配。
  因为之前的授权请求根本没有被持久存储，校验直接失败，过滤器会判定本次回调为无效请求，自动触发引导用户重新发起授权流程的逻辑。

这就形成了固定的循环链路：跳转Facebook授权→回调应用→校验失败→重新跳转Facebook授权→再次回调，最终触发浏览器的“重定向次数过多”报错。

注意：这里的冲突和最终的用户接口认证是否使用Session无关——很多团队为了实现无状态API、用JWT做接口鉴权，会一刀切把整条过滤器链的会话策略设为STATELESS，但OAuth2登录流程的临时校验数据存储，本身就是强依赖HttpSession的，一刀切配置就会直接打断流程。只有将授权请求的存储逻辑从默认的HttpSession实现，替换为独立的内存、Redis存储方案后，才可以安全地在OAuth2登录链路上开启STATELESS策略。

内容的提问来源于stack exchange，提问作者Almir James Lucena