Spring Boot 3.x + Security + OpenFeign：如何避免内部服务调用被重复拦截？
大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。
图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG
我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。
展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！
文章目录
- 前言
- 需求场景分析
- 常见坑点
- 解决思路
- 代码实战
- 1. Feign 请求加上 client_token
- 2. 自定义认证过滤器
- 3. Security 配置双认证逻辑
- 4. 用户 token 认证
- 实际场景结合
- 总结
前言
在微服务架构里，外部请求和内部服务调用的认证逻辑往往不一样。
比如外部用户访问接口时，必须用 user_token 来校验身份；而服务之间（比如服务 A 调用服务 B）只需要用 client_token 来表明这是内部调用，不必再走一遍复杂的用户认证。
但是问题来了：
用户带着 access_token 请求服务 A，A 会先过 Spring Security 的过滤器。这个过滤器里我们要远程调用服务 B 验证 access_token，结果 Feign 请求又被 Security 拦了一次，导致认证死循环。
那要怎么破？本文就来聊聊这个场景的实战解法。
需求场景分析
我们先把需求捋清楚：
-
外部请求：
- 必须携带
user_token - 通过服务 A 时，Spring Security 要走用户认证逻辑
- 必须携带
-
服务间调用：
- Feign 调用必须带
client_token - 服务 B 收到请求时，只要验证这个
client_token就行，不必再走用户认证
- Feign 调用必须带
-
问题点：
- 当 A 的 Security 过滤器里用 Feign 调服务 B 验证
access_token时，这个请求也会被拦截，导致无限套娃
- 当 A 的 Security 过滤器里用 Feign 调服务 B 验证
常见坑点
-
没区分 token 类型：
用户 token 和 client token 混在一起，所有请求都走同一套拦截逻辑。 -
Feign 默认带全局拦截：
Spring Security 的OncePerRequestFilter会作用于所有请求，包括 Feign 发起的内部请求。 -
死循环风险：
A 调 B 校验 token，B 又拦截成用户请求 → 又要去 A 验证 → 死循环。
所以我们必须设计一套机制，让外部请求和内部调用走不同的认证逻辑。
解决思路
-
区分两类请求：
- 用户请求：带
Authorization: Bearer user_token - 内部调用：带
X-Client-Token: client_token
- 用户请求：带
-
Spring Security 配置双认证链：
- 用户请求必须走 JWT 校验逻辑
- 内部调用只校验
client_token，绕过用户认证
-
Feign 请求统一加 client_token：
- 用
RequestInterceptor给 Feign 请求自动加X-Client-Token
- 用
代码实战
下面用 Spring Boot 3.x 写一个简化版 Demo，演示完整流程。
1. Feign 请求加上 client_token
import feign.RequestInterceptor;
import feign.RequestTemplate;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;@Configuration
public class FeignConfig {@Beanpublic RequestInterceptor clientTokenInterceptor() {return (RequestTemplate template) -> {// 模拟内部服务调用的 client_token，可以从配置中心或 Vault 获取template.header("X-Client-Token", "my-client-token-123");};}
}
这样每次服务 A 调用服务 B，都会带上 X-Client-Token。
2. 自定义认证过滤器
我们需要两个过滤器，一个处理用户 token，一个处理 client token。
import jakarta.servlet.FilterChain;
import jakarta.servlet.ServletException;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.authentication.WebAuthenticationDetailsSource;
import org.springframework.web.filter.OncePerRequestFilter;import java.io.IOException;public class ClientTokenFilter extends OncePerRequestFilter {private final String CLIENT_TOKEN = "my-client-token-123";@Overrideprotected void doFilterInternal(HttpServletRequest request,HttpServletResponse response,FilterChain filterChain)throws ServletException, IOException {String clientToken = request.getHeader("X-Client-Token");if (clientToken != null && clientToken.equals(CLIENT_TOKEN)) {// 直接认证为内部服务角色UsernamePasswordAuthenticationToken authentication =new UsernamePasswordAuthenticationToken("internal-service", null, null);authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request));SecurityContextHolder.getContext().setAuthentication(authentication);}filterChain.doFilter(request, response);}
}
这里的逻辑很简单：
- 如果请求头有
X-Client-Token并且正确 → 直接放行，视为内部请求 - 没有的话就交给后面的用户认证逻辑去处理
3. Security 配置双认证逻辑
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;@Configuration
public class SecurityConfig {@Beanpublic SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {http.csrf(csrf -> csrf.disable());http.authorizeHttpRequests(auth -> auth.requestMatchers("/public/**").permitAll().anyRequest().authenticated());// client token filter 优先级要高于 user token filterhttp.addFilterBefore(new ClientTokenFilter(), UsernamePasswordAuthenticationFilter.class);http.addFilterBefore(new UserTokenFilter(), UsernamePasswordAuthenticationFilter.class);return http.build();}
}
这里我们把 ClientTokenFilter 放在前面，这样内部调用会优先匹配，不会再进入用户认证逻辑。
4. 用户 token 认证
public class UserTokenFilter extends OncePerRequestFilter {@Overrideprotected void doFilterInternal(HttpServletRequest request,HttpServletResponse response,FilterChain filterChain)throws ServletException, IOException {String authHeader = request.getHeader("Authorization");if (authHeader != null && authHeader.startsWith("Bearer ")) {String userToken = authHeader.substring(7);// TODO: 调用服务 B 验证 user_token，有效的话设置用户上下文// 这里省略 JWT 验证逻辑}filterChain.doFilter(request, response);}
}
这样就能保证：
- 外部请求 →
Authorization: Bearer user_token→ 走UserTokenFilter - 内部调用 →
X-Client-Token: client_token→ 走ClientTokenFilter
实际场景结合
设想一下：
- 用户小明用 app 登录，请求
/api/orders带着user_token。 - 服务 A 收到请求，要调用服务 B 校验
user_token。 - Feign 调用时带上了
X-Client-Token，所以服务 B 不会再拦截成用户请求，而是识别成内部调用。 - 服务 B 验证成功后返回结果，A 才继续执行业务逻辑。
这样就避免了死循环，既保证了安全性，又把内部调用和外部请求分开了。
总结
这个问题的核心是 区分外部请求和内部调用的认证链路：
- 给 Feign 调用统一加
client_token - 在 Security 里加一个
ClientTokenFilter，专门处理内部请求 - 用户请求继续走 JWT 或 access_token 的逻辑
- 通过过滤器顺序，避免 Feign 调用再触发用户认证，彻底解决死循环