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 拦了一次，导致认证死循环。

那要怎么破？本文就来聊聊这个场景的实战解法。

需求场景分析

我们先把需求捋清楚：

1. 外部请求：

   • 必须携带 user_token
   • 通过服务 A 时，Spring Security 要走用户认证逻辑

2. 服务间调用：

   • Feign 调用必须带 client_token
   • 服务 B 收到请求时，只要验证这个 client_token 就行，不必再走用户认证

3. 问题点：

   • 当 A 的 Security 过滤器里用 Feign 调服务 B 验证 access_token 时，这个请求也会被拦截，导致无限套娃

常见坑点

• 没区分 token 类型：
  用户 token 和 client token 混在一起，所有请求都走同一套拦截逻辑。

• Feign 默认带全局拦截：
  Spring Security 的 OncePerRequestFilter 会作用于所有请求，包括 Feign 发起的内部请求。

• 死循环风险：
  A 调 B 校验 token，B 又拦截成用户请求 → 又要去 A 验证 → 死循环。

所以我们必须设计一套机制，让外部请求和内部调用走不同的认证逻辑。

解决思路

1. 区分两类请求：

   • 用户请求：带 Authorization: Bearer user_token
   • 内部调用：带 X-Client-Token: client_token

2. Spring Security 配置双认证链：

   • 用户请求必须走 JWT 校验逻辑
   • 内部调用只校验 client_token，绕过用户认证

3. 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 {
@Bean
public 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";
@Override
protected 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 {
@Bean
public 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 filter
http.addFilterBefore(new ClientTokenFilter(), UsernamePasswordAuthenticationFilter.class);
http.addFilterBefore(new UserTokenFilter(), UsernamePasswordAuthenticationFilter.class);
return http.build();
}
}

这里我们把 ClientTokenFilter 放在前面，这样内部调用会优先匹配，不会再进入用户认证逻辑。

4. 用户 token 认证

public class UserTokenFilter extends OncePerRequestFilter {
@Override
protected 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 才继续执行业务逻辑。

这样就避免了死循环，既保证了安全性，又把内部调用和外部请求分开了。

总结

这个问题的核心是 区分外部请求和内部调用的认证链路：

1. 给 Feign 调用统一加 client_token
2. 在 Security 里加一个 ClientTokenFilter，专门处理内部请求
3. 用户请求继续走 JWT 或 access_token 的逻辑
4. 通过过滤器顺序，避免 Feign 调用再触发用户认证，彻底解决死循环