Spring Security放行指定URL不生效 访问refreshToken接口返回403

自定义过滤器里的直接放行逻辑，仅跳过了你自己写的token校验分支，没有绕过Spring Security内置的权限拦截链路。
核心矛盾点来自两处配置的执行逻辑：

1. 你配置的全局权限规则中，明确给/admin/**下的所有路径设置了authenticated()要求——也就是必须携带有效认证信息才能访问，/admin/users/refreshToken完全匹配这个路径规则。
2. 过滤器的执行顺序上，你自定义的CustomAuthorizationFilter注册在UsernamePasswordAuthenticationFilter之前，就算你在这个过滤器里直接调用filterChain.doFilter()放行请求，请求最终还是会走到Spring Security内置的FilterSecurityInterceptor（负责最终权限判定的核心过滤器）。由于你开启了SessionCreationPolicy.STATELESS无状态模式，不会从会话中读取认证信息，此时SecurityContext中没有任何有效认证对象，权限校验不通过直接返回403，和你前面自定义过滤器的放行逻辑没有关系。

两种实现方式二选一即可，优先选第一种，维护成本更低：

• 方案一：在全局权限规则中给目标路径加白名单，注意白名单路径必须写在/admin/**规则之前，Spring Security的路径匹配是按配置顺序优先匹配先声明的规则：

http.authorizeRequests()
        .antMatchers("/login", "/admin/users/refreshToken").permitAll()
        .antMatchers("/admin/**").authenticated()
        .anyRequest().permitAll();

配置完成后，这两个路径会直接跳过认证要求，不需要在自定义过滤器里额外写分支放行。

• 方案二：如果需要把白名单逻辑收敛在自定义过滤器中处理，那在匹配到放行路径时，提前往SecurityContext中注入匿名认证对象再向后传递请求，这样后续权限校验能拿到合法的认证标识就不会拦截。但这种方式会把白名单逻辑散落在过滤器代码里，后续迭代很容易漏改，不推荐使用。

内容的提问来源于stack exchange，提问作者Джейк Морган