本文详解如何在 Spring Security 6+（配合 Spring Authorization Server）中正确配置无需 Bearer Token 即可访问的 HTTP 端点，重点解决因 permitAll() 顺序错误导致的 401 Unauthorized 问题。
本文详解如何在 spring security 6+（配合 spring authorization server）中正确配置无需 bearer token 即可访问的 http 端点，重点解决因 `permitall()` 顺序错误导致的 401 unauthorized 问题。
在 Spring Security 中，请求匹配规则的声明顺序至关重要——安全配置采用“自上而下、首个匹配即生效”的策略。若将 .anyRequest().authenticated() 放置在 .requestMatchers(...).permitAll() 之前，所有请求将优先匹配 anyRequest 规则并强制要求认证，后续的 permitAll() 将被完全忽略，从而导致本应公开的端点（如 /api/order/process/result）仍返回 401 Unauthorized。
✅ 正确配置：确保 permitAll() 规则前置
请严格按以下顺序编写 authorizeHttpRequests 配置：
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.cors().and()
.csrf().disable()
.authorizeHttpRequests(auth -> auth
// ✅ 第一步：明确声明免认证路径（必须放在 anyRequest 之前！）
.requestMatchers(HttpMethod.POST, "/api/order/process/result").permitAll()
// ✅ 第二步：其他所有请求均需认证
.anyRequest().authenticated()
)
.oauth2ResourceServer(oauth2 -> oauth2
.jwt(jwt -> jwt.jwkSetUri(jwksUri))
);
return http.build();
}
⚠️ 注意事项：
- requestMatchers() 必须指定 HttpMethod（如 HttpMethod.POST），而非仅路径字符串，否则可能因方法不匹配而失效；
- 使用 permitAll() 表示完全跳过认证与授权检查（不校验 JWT、不解析 Authorization: Bearer 头），适用于 Webhook 回调、健康检查等场景；
- 若该端点需接收非 JSON 内容（如原始字符串、表单数据），请同步确认 @PostMapping 的 consumes 属性与客户端实际 Content-Type 一致（当前配置 APPLICATION_JSON_VALUE 合理，但需确保请求头含 Content-Type: application/json）；
- permitAll() ≠ anonymous()：前者彻底绕过 Security Filter Chain，后者仍进入链路但允许匿名身份；此处应使用 permitAll()。
? 验证是否生效
启动应用后，执行以下 cURL 测试（不带 Authorization 头）：
curl -X POST http://localhost:8080/api/order/process/result \
-H "Content-Type: application/json" \
-d '{"Body":{"stkCallback":{"ResultCode":0}}}'
预期响应状态码为 200 OK，而非 401。
? 补充建议
-
日志调试：启用 Spring Security 调试日志快速定位匹配逻辑：
logging: level: org.springframework.security: DEBUG -
路径通配优化：若未来需开放多个回调端点，可统一归组：
.requestMatchers(HttpMethod.POST, "/api/order/**", "/api/webhook/**").permitAll()
- 安全性提醒：permitAll() 端点仍受 CORS、CSRF（已禁用）、防火墙等保护，请勿在生产环境对敏感操作开放此权限。
遵循上述顺序与规范，即可确保资源服务器精准识别并放行指定免认证端点，彻底规避因规则顺序引发的认证拦截问题。
