Spring Boot配置Azure AD无状态会话登录循环与Swagger授权冲突问题

两个异常现象的核心逻辑非常明确：

1. 全局配置SessionCreationPolicy.STATELESS后触发无限登录循环：AAD使用的OAuth2授权码登录流程，需要依赖Session临时存储state、nonce等防CSRF校验参数，全局无状态会强制服务端不存储任何会话数据，AAD认证回调时拿不到预先存储的校验参数，会直接判定认证失败并重定向回登录页，最终形成死循环。
2. 移除无状态配置后Swagger与业务授权状态串用：默认配置下所有路径共享根路径下的JSESSIONID会话Cookie，Swagger和业务接口没有做路径级的安全规则隔离，服务端SecurityContext、会话数据完全共用，自然会出现互相读取授权信息、Swagger登出失效的问题。
3. 配置项spring.cloud.azure.active-directory.sessions-stateless=true不生效：手动编写的HttpSecurity配置优先级高于Azure AD Starter的自动配置，该配置项会被自定义的全局会话规则覆盖；且该配置仅针对AAD资源服务器（纯Token校验）场景设计，不适用于带登录跳转的授权码流程场景。

优先选择路径级安全规则隔离方案，不需要改动现有业务逻辑，从根源避免状态串用：

方案1：拆分多SecurityFilterChain，为Swagger和业务接口配置独立规则 #

Spring Security支持按优先级配置多个独立的安全过滤链，不同路径匹配完全独立的会话、认证规则，实现状态隔离：

1. 为Swagger相关路径配置高优先级独立过滤链，使用独立的有状态会话规则，和业务逻辑完全拆分：

@Bean
@Order(1) // 优先级最高，优先匹配Swagger路径
public SecurityFilterChain swaggerSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        // 仅拦截Swagger相关路径
        .securityMatcher("/swagger-ui/**", "/v3/api-docs/**", "/swagger-ui.html", "/swagger-resources/**", "/webjars/**")
        .authorizeHttpRequests(auth -> auth
            // 可按需配置Swagger访问权限，开发环境可直接permitAll，生产环境建议直接禁用Swagger
            .anyRequest().permitAll()
        )
        // Swagger路径独立使用有状态会话策略，不影响业务接口
        .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED))
        .csrf(csrf -> csrf.ignoringRequestMatchers("/swagger-ui/**", "/v3/api-docs/**"));
    return http.build();
}

2. 为业务接口配置低优先级过滤链，仅对业务路径开启无状态策略，注意放行OAuth2登录回调路径：

@Bean
@Order(2)
public SecurityFilterChain businessApiSecurityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // 放行AAD登录回调端点，这部分路径需要Session存储校验参数
            .requestMatchers("/login/oauth2/code/**").permitAll()
            .anyRequest().authenticated()
        )
        // 仅业务接口使用无状态策略，基于Token校验权限，不创建Session
        .sessionManagement(session -> session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
        // 配置AAD资源服务器Token校验规则
        .oauth2ResourceServer(oauth2 -> oauth2.jwt(Customizer.withDefaults()));
    return http.build();
}

配置完成后两个路径的过滤链完全独立，会话数据互不干扰，既不会出现登录循环，也不会出现Swagger和业务授权状态串用的问题。

方案2：Swagger改用纯Token认证，完全不依赖服务端Session #

如果不想拆分过滤链，可以直接修改Swagger的认证配置，不走OAuth2登录跳转，改为手动填入JWT Token的模式，Swagger的认证状态只存在前端，完全不读写服务端Session：

@Bean
public OpenAPI customOpenAPI() {
    return new OpenAPI()
        .addSecurityItem(new SecurityRequirement().addList("AAD JWT"))
        .components(new Components()
            .addSecuritySchemes("AAD JWT", new SecurityScheme()
                .type(SecurityScheme.Type.HTTP)
                .scheme("bearer")
                .bearerFormat("JWT")
                .in(SecurityScheme.In.HEADER)
                .name("Authorization")
            )
        );
}

配置后Swagger页面的Authorize按钮只需要手动填入从AAD拿到的有效JWT，所有接口请求自动携带Authorization头发起，不会触发服务端登录跳转，也不会读写服务端会话，登出按钮直接清理前端存储的Token，完全不存在状态串用、登出失效的问题，实现成本最低。

• 不要在使用OAuth2授权码登录、表单登录等需要服务端存储临时凭证的场景下全局配置SessionCreationPolicy.STATELESS，必然会导致登录流程断裂。
• 生产环境建议直接禁用Swagger，从根源避免Swagger相关的安全和状态干扰问题。

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