Spring WebFlux自定义SecurityFilter扩展多授权类型方案咨询

你当前基于自定义WebFilter实现Bearer令牌校验的方案可以正常运行，但后续如果要扩展新的授权类型，直接在现有SecurityFilter和AccessTokenProvider里新增特定方法的做法不可取，耦合度太高，不符合开闭原则，后续授权类型加的越多，代码越难维护。

• 核心认证逻辑硬编码：SecurityFilter里写死了Bearer令牌的解析、校验分支，后续新增JWT、API Key等授权方式时，必须不断修改Filter的核心判断流程，迭代多了很容易引入逻辑漏洞
• 类职责不单一：现在的AccessTokenProvider只负责对接外部令牌交换服务，如果把JWT本地验签、解析这类逻辑也塞进去，会让这个类变成混杂所有授权逻辑的大杂烩
• 重复造轮子：你已经引入了Spring WebFlux Security依赖（使用了@EnableWebFluxSecurity注解），但完全没用到框架原生的认证、安全上下文、异常处理抽象，自己实现了整套路径拦截、校验逻辑，额外增加了维护成本
• 存在资源泄漏隐患：当前AccessTokenProvider里每次调用exchangeToken都新建WebClient实例，没有复用连接池，高并发场景下会出现连接资源泄漏的问题。

不要在原有类上累加逻辑，按职责拆分抽象，基于策略模式实现扩展：

1. 定义统一认证策略接口
   所有授权类型都实现这个公共接口，新增授权类型时只需要加新的实现类，不需要修改核心Filter逻辑：

public interface ReactiveAuthHandler {
    // 判断当前请求是否匹配该认证处理器，比如Bearer认证就判断Authorization头是否以"Bearer "开头
    Mono<Boolean> support(ServerWebExchange exchange);
    // 执行实际认证逻辑，认证通过返回带用户/客户端信息的认证对象，失败抛出401异常
    Mono<AuthenticatedPrincipal> doAuth(ServerWebExchange exchange);
}

你当前的外部令牌交换Bearer校验逻辑，单独封装为BearerExchangeAuthHandler实现类；后续要加JWT认证，就新增JwtLocalVerifyAuthHandler实现类，两类逻辑完全隔离。

2. 改造SecurityFilter为通用流程调度器
   改造后的Filter不再硬编码某一种认证逻辑，只做通用流程处理：

• 先判断请求路径是否在受保护路径集合里，非受保护路径直接放行
• 遍历容器中所有注入的ReactiveAuthHandler实现，找到第一个支持当前请求的处理器
• 调用对应处理器的认证方法，认证通过就把认证信息存入上下文后放行，找不到匹配处理器、认证失败直接返回401

如果你不想自己维护Filter逻辑，也可以直接复用Spring Security原生的扩展点：实现自定义ReactiveAuthenticationManager和ServerAuthenticationConverter，把多认证类型的逻辑接入框架的认证链，稳定性更高，不用自己处理安全上下文存储、异常响应封装这类通用逻辑。

3. 拆分Token处理层职责
   把原有的AccessTokenProvider定位为专门对接外部令牌交换服务的HTTP客户端，只负责发起请求、解析响应，不掺杂令牌合法性判断、scope校验这类业务逻辑；JWT的验签、解析逻辑单独封装JwtTokenProcessor，不同类型的令牌处理逻辑完全拆分，互不影响。

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