Spring Security多WebSecurityConfigurerAdapter配置@Order仅首个生效问题

首先明确：你设想的这种按不同路径拆分安全过滤链、分别适配JWT/OpenLDAP与Salesforce OAuth2鉴权体系的实现方式完全可行，当前的异常现象并不是方案本身的问题，是对多WebSecurityConfigurerAdapter的匹配规则理解不到位踩了常见的配置坑。

异常根因分析 #

Spring Security 多安全配置的执行逻辑是：按@Order标注的优先级从高到低依次匹配请求，优先级高的配置如果没有通过securityMatcher限定自己的拦截路径范围，默认会接管所有进来的请求，后续低优先级的配置完全没有执行机会。
你当前的两个配置类都没有给自身限定专属的拦截路径边界，默认都是全路径拦截，因此会出现两种异常表现：

• 当@Order(1)为JWT/OpenLDAP配置时，它会接管所有请求，包括本属于OAuth2链路的/client/**路径。这些/client路径的请求会被塞进JWT过滤器链处理，完全触发不了后续的OAuth2登录流程，因此访问/client时会抛出OAuth2相关错误
• 当调换@Order顺序，把OAuth2配置放到优先级1的位置时，它同样会接管所有请求，把原本属于JWT链路的/user/**路径全部纳入OAuth2过滤链，原本的JWT/OpenLDAP过滤器根本不会执行，因此/user接口会完全失去安全校验逻辑

改造步骤 #

1. 给每个配置类明确划定专属拦截范围 #

在两个继承WebSecurityConfigurerAdapter的实现类中，重写configure(WebSecurity web)方法，用securityMatcher给每个配置指定自己负责的路径，从根源上避免全路径接管的问题：

• 标注@Order(1)的JWT/OpenLDAP配置类：

  @Override
  public void configure(WebSecurity web) throws Exception {
      // 只负责拦截/user/**路径，其他请求直接跳过本配置，交给低优先级配置处理
      web.securityMatcher("/user/**");
  }
  

• 标注@Order(2)的Salesforce OAuth2配置类：

  @Override
  public void configure(WebSecurity web) throws Exception {
      // 只负责拦截/client及/client下的所有子路径
      web.securityMatcher("/client", "/client/**");
  }
  

2. 对应简化HttpSecurity配置 #

划定拦截范围后，原来配置里写的路径匹配规则可以简化：

• JWT配置类中，无需再单独写/user/**的鉴权规则——因为该配置只拦截/user/**请求，直接对被拦截的请求统一设置“已登录才可访问”的规则即可，原有的/user/login路径放行、JWT过滤器注册、OpenLDAP鉴权配置全部可以保留
• OAuth2配置类中，也无需单独写/client、/client/**的鉴权规则，直接对被拦截的请求开启OAuth2登录流程即可，原有的MyOAuth2UserService注入配置可以保留

3. 关键配置注意项 #

• JWT鉴权的/user体系保持原有SessionCreationPolicy.STATELESS的无状态会话策略即可，无需改动
• OAuth2的/client体系不需要强制设置无状态会话，保留默认的会话策略即可正常维持Salesforce登录的会话状态
• 两个配置各自的CORS、CSRF、frameOptions规则可以独立设置，不存在冲突

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