微服务间Feign调用如何跳过认证？白名单与内部标记方案详解

打开某个老项目时我一度很困惑明明A服务通过Feign调用B服务已经写得明明白白结果对方那边每次都在认证环节直接把我拦回来日志里一溜的401。其实这个问题的本质并不复杂——这就是“微服务之间调用部分Feign接口需要忽略认证授权”的典型场景服务间调用本来就不该走完整的用户认证链路。这篇内容主要围绕这个需求展开聊清楚哪些场景该跳、哪些场景不该跳以及最常见的白名单方案、内部调用标记方案分别怎么落地适合正在维护Spring Cloud微服务项目、被服务间鉴权搞得焦头烂额的开发者参考。1. 那些必须跳过认证的真实业务场景不做服务间调用的项目几乎体会不到这种痛点。表面上看每个服务都把token校验写在拦截器里谁调用都校验一下挺安全的。但在实际业务里这种“一刀切”很快就会变成灾难。1.1 用户上下文不存在时的典型场景最典型的场景是定时任务触发的批量处理。比如订单服务每天凌晨扫描超时未支付的订单然后调用支付服务做关闭支付操作。这个时候根本没有“当前用户”只有任务调度平台发起的后台执行。你要强制它带一个用户token那是一种折磨。还有一种非常常见的场景服务间的状态同步。用户下单后订单服务需要通知库存服务扣减库存、通知积分服务增加积分。这些操作都是为了完成一个业务闭环在业务链路里它们更多是“服务身份”在调用而不是“某个用户身份”在调用。如果所有接口都强制要求userId你会发现代码里全是伪造用户上下文的骚操作。另外就是内部数据查询类的接口。比如用户服务需要从订单服务拉一批统计数据用来做报表展示。这种接口如果被用户的token逻辑卡住往往就需要架构师专门去开通白名单否则整个数据分析的链路直接断掉。1.2 哪些调用反而必须保留用户认证跳过认证不是无条件的我见过不少团队把不该跳的也跳了最后线上出现越权问题。下面这些场景建议保留完整的用户认证链路业务场景是否跳过原因定时任务触发服务间操作跳过无用户上下文且调用方可信服务间数据同步与对账跳过属于内部业务闭环服务内部报表聚合查询跳过不涉及用户维度的权限隔离用户主动发起的查询接口不跳过必须校验登录状态与操作权限涉及用户数据越权风险的写操作不跳过必须识别真实操作者便于审计第三方开放平台回调触发操作不跳过需要验证第三方身份不能只靠内部信任判断标准其实就一条这个调用是否真的有“用户主体”存在如果调用来自用户请求链路哪怕中间转了好几跳也应该把用户身份透传下去如果调用来自后台任务、消息队列消费、服务间同步那它天然没有用户主体强制走用户认证就是在制造技术债。1.3 为什么不能图省事全部放行有些团队嫌麻烦干脆把服务间所有Feign接口的认证都关掉。这在短期内确实能跑通所有业务但迟早会出问题。最直接的风险是服务间的接口如果全部裸奔一旦某个服务被攻破攻击者可以横向调用任意内部接口而且审计日志里什么都查不到。更隐蔽的问题是接口一旦习惯性裸奔后续新开发的同学就不知道哪些接口是有权限控制的越权操作就这么慢慢长出来了。所以正确的心态不是“图省事全部放行”而是“有边界地、有条件地跳过认证”。这也是我写这篇分享的核心态度跳过认证可以但要让系统知道你跳过了什么、为什么跳、是谁在跳。2. 两种主流的“忽略认证授权”实现思路与边界明确了需要跳过的场景之后真正的问题是技术上怎么实现“跳过”才是安全的、可维护的、可审计的。我在几个项目里试过不同的做法概括下来其实就是两条路URL白名单放行以及基于Feign内部调用标记的放行。两条路各有各的边界选错方案的代价后期都会在线上体现。2.1 思路一URL白名单直接放行这是最朴素、最容易想到的方案。被调用方在认证拦截器里维护一份忽略校验的地址列表如果请求路径命中了列表里的规则直接放行不解析token、不校验权限。配置大概长这样auth: ignore-urls: - /api/internal/** # 内部服务间调用接口统一前缀 - /inner/order/** # 内部订单查询 - /actuator/health # 健康检查接口通常也要放行拦截器里按AntPattern匹配即可public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { String uri request.getRequestURI(); boolean matched authProperties.getIgnoreUrls().stream() .anyMatch(pattern - new AntPathMatcher().match(pattern, uri)); if (matched) { return true; // 忽略认证授权 } // 继续走正常token校验逻辑 // ... return true; }这个方案优点很明显实现简单几天就能铺完排查问题直观——看到一个路径放了就放行了。缺点也同样明显它只判断了路径不判断调用者身份。任何能直接访问到这个服务的请求只要拼对路径都能避开认证。如果服务暴露在公网或非隔离内网风险非常大。2.2 思路二Feign内部调用标记放行第二种方案比白名单安全一个层级。Feign在发起调用时通过自定义RequestInterceptor往请求头里注入一个内部标记例如X-Internal-Call: true。服务端在认证拦截器里先判断这个标记是否存在且合法合法就直接跳过用户认证。Feign侧的拦截器代码public class InternalCallFeignInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { template.header(X-Internal-Call, true); template.header(X-Caller-Service, order-service); } }服务端侧的校验逻辑public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 先识别内部调用标记 if (true.equals(request.getHeader(X-Internal-Call))) { return true; // 内部服务间调用跳过用户认证 } // 再走白名单逻辑 String uri request.getRequestURI(); boolean matched authProperties.getIgnoreUrls().stream() .anyMatch(pattern - new AntPathMatcher().match(pattern, uri)); if (matched) { return true; } // 最后才是正常的token认证 // ... return true; }这个方案相对安全的原因是它在“路径”之外多了一层“来源身份”的判断。但这里有个极易被忽略的隐患——X-Internal-Call这个请求头是明文名称如果一个外部请求绕过网关直接打到服务端口也能自己伪造这个Header。所以这个方案还需要一个配套动作要么网关层统一剥离掉这个头要么服务端进一步校验签名不然它只是看起来比白名单强一点而已。2.3 两者怎么选从我的实践经验来看不存在绝对最优只有最合适的组合策略对比维度URL白名单Feign内部标记实现成本低配置即生效中需要写拦截器并管理请求头维护直观性高看配置就知道哪些接口放行中需要看源码才能理解拦截逻辑安全强度低路径可预测即可能被利用中需要配合网络隔离或签名适合场景健康检查、回调接口、内部公开接口服务间业务调用、对身份敏感的内部链路我个人的倾向很明确能用内部标记解决的不要只依赖白名单。白名单适合那些“匿名也能访问”的接口比如健康检查、部分回调内部标记适合那些“只有可信服务才能访问”的业务接口。把两类混在一起用同一套逻辑后面维护时会很痛苦。3. 落地实战白名单放行加Feign标记的双层配合理论聊再多不如把一套真正可复用的配置和代码贴出来。下面这套是我在普通Spring Cloud项目里验证过的做法服务端拦截器保留两层判断内部标记优先、白名单兜底Feign侧统一注入调用方身份再用网关层挡住外部伪造请求。3.1 服务端拦截器完整版代码先说核心部分自定义一个认证拦截器在进入Controller之前完成三层判断内部调用标记、白名单路径、正常token校验。Component public class AuthInterceptor implements HandlerInterceptor { private final AuthProperties authProperties; public AuthInterceptor(AuthProperties authProperties) { this.authProperties authProperties; } Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 第一层内部服务调用标记 if (true.equals(request.getHeader(X-Internal-Call))) { // 建议在这里校验调用方服务名确认在允许的列表里 String caller request.getHeader(X-Caller-Service); if (authProperties.getAllowedCallers().contains(caller)) { return true; } } // 第二层白名单路径放行 String uri request.getRequestURI(); boolean inWhiteList authProperties.getIgnoreUrls().stream() .anyMatch(pattern - new AntPathMatcher().match(pattern, uri)); if (inWhiteList) { return true; } // 第三层正常token解析与校验 String token request.getHeader(Authorization); if (!isValidToken(token)) { response.setStatus(HttpStatus.UNAUTHORIZED.value()); return false; } return true; } private boolean isValidToken(String token) { // 这里对接你的认证服务或JWT解析逻辑 return token ! null token.startsWith(Bearer ); } }然后通过WebMvcConfigurer注册这个拦截器并设置拦截路径Configuration public class WebMvcConfig implements WebMvcConfigurer { private final AuthInterceptor authInterceptor; public WebMvcConfig(AuthInterceptor authInterceptor) { this.authInterceptor authInterceptor; } Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(authInterceptor) .addPathPatterns(/api/**) .excludePathPatterns(/api/auth/**); // 登录接口本身放行 } }这里有个细节值得说一下拦截器不要配置成拦截所有路径只对需要保护的业务路径生效避免把Spring Boot的Error接口、静态资源也卷进认证逻辑里。3.2 配置项统一外置为了让运维和开发不用每次改代码把关键配置全部放到配置文件里。用Nacos或Apollo管理最好本地yml也能跑auth: ignore-urls: - /api/internal/** allowed-callers: - order-service - user-service - gateway-service配合RefreshScope就能实现动态刷新这一点我在后面的踩坑部分会再展开。3.3 Feign侧给所有客户端统一加内部标记在服务启动时定义一个全局的FeignRequestInterceptor。这样所有的Feign客户端调用都会带上内部身份头不需要每个FeignClient单独配置。Configuration public class FeignClientConfiguration { Bean public RequestInterceptor internalCallRequestInterceptor() { return new InternalCallFeignInterceptor(); } }拦截器具体实现public class InternalCallFeignInterceptor implements RequestInterceptor { Override public void apply(RequestTemplate template) { template.header(X-Internal-Call, true); template.header(X-Caller-Service, getCurrentServiceName()); } private String getCurrentServiceName() { // 优先取环境变量或配置 return order-service; } }如果你项目里有部分FeignClient是用来调第三方外部接口的那就别用全局拦截器改成按客户端指定configurationFeignClient(name stock-service, configuration InternalFeignConfig.class) public interface StockFeignClient { ... }这一点特别容易踩坑我见过有团队在全局配了拦截器结果对外API的所有Feign请求都带上了内部标记对方一看头都大了。3.4 网关层也要配合放行整个链路里最容易被忽略的反而是网关。如果你架构里有Spring Cloud Gateway外部请求先过网关这时即使服务内部已经放行了内部标记网关这一层如果对token校验有强逻辑还是会直接把请求拦下来。网关层面的处理思路其实很清晰把“不需要用户认证的内部路径”也加入网关白名单并且最好在网关层直接剥离掉不可信的请求头。我一般会在网关里放一个过滤器做两件事public class InternalCallFilter implements GlobalFilter, Ordered { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); String path request.getURI().getPath(); // 网关白名单路径提前放行 if (isInWhiteList(path)) { return chain.filter(exchange); } // 非白名单路径去掉内部调用标记防止外部伪造 ServerHttpRequest mutatedRequest request.mutate() .headers(headers - headers.remove(X-Internal-Call)) .build(); return chain.filter(exchange.mutate().request(mutatedRequest).build()); } }这一步做的核心动作就是“剥离”外部来的请求一律不允许携带内部调用标记避免有人直接伪造请求打服务。内网隔离更严格的话这一步可能是多余的但只要服务还可能被外部访问到剥离动作就很有必要。4. 这几个坑我基本都踩过理论方案看完了代码也贴完了接下来这部分才是真正值钱的经验。以下每个问题都是我在实际项目里真真切切遇到的有些问题排查了一个下午才发现原因。4.1 坑一服务内放行了网关还把你拦在外面还是网关配合的问题。很多团队服务端的拦截器已经放行了内部调用标记但网关的GlobalFilter只认Authorization头一看到没有token就直接转发到登录逻辑请求压根没进到目标服务。排查这类问题的时候第一件事就是梳理请求走了哪几层过滤客户端到网关、网关到服务、服务内部拦截器、最后才是Controller。每一层都会漏。我现在的习惯是明确把“认证校验”这一职责划分给某一层其他层只透传或剥离不做二次校验避免每层都加一道锁导致互相矛盾。4.2 坑二Feign默认不会传递原请求头我当时犯过一个很低级的错误以为Feign调用时会把当前HTTP请求的Header自动带过去。实际上Spring Cloud OpenFeign默认不会透传原请求的Header包括Cookie和Authorization。只有显式配置RequestInterceptor之后才会把需要的信息加到新的请求里。这带来的连锁反应是如果业务链路是用户请求到网关、网关到服务A、服务A通过Feign调服务B那你服务B那边看到的只有你的自定义Header没有原始用户的Authorization。所以要么你在每跳Feign调用时手动透传用户token要么就像这里说的直接采用内部调用标记跳过用户认证不要把用户token层层搬运。我的建议是用户身份该透传的透传服务身份该跳过的跳过两条线不要混。还有一个隐蔽版本的问题当你用了Hystrix信号量隔离或线程池隔离时如果认证信息放在线程上下文里Feign拦截器在另一个线程里运行时取不到也会导致认证信息丢失。如果确实需要透传可以考虑用TransmittableThreadLocal配合实现上下文传递。4.3 坑三AntPathMatcher路径匹配的过度放行这个坑很搞心态。/api/internal/**和/api/internal/*看起来只差一个星号实际匹配范围完全不同。前者匹配/api/internal/order/detail后者只匹配/api/internal/order不会继续往下匹配多级路径。更危险的是有人配置的时候写成了/api/*觉得这是内部路径前缀放行结果所有/api/order、/api/user的接口全部免认证了。排查这种问题的唯一有效方式就是写几个本地单元测试把每个配置项实际匹配到的路径全部打出来看一遍不要靠肉眼判断。我还遇到过另一个相关的问题服务里统一加了servlet context path比如所有请求都带/order-service前缀但白名单配置里没带前缀导致/api/internal压根匹配不上。这个微调很烦人因为本地调试时没有前缀测试环境有前缀两边表现完全不一样。4.4 坑四只做了放行没做来源校验有段时间我的服务端只做了白名单判断结果发现外部直接把内部接口路径摸出来绕过登录就调走了。原因就是白名单只判断“路径可不可访问”不判断“谁在访问”。给内部调用做来源校验至少要有下面这些手段之一校验调用方服务名是否在允许列表里网关剥掉外部请求携带的内部标记网络层隔离内部接口只允许内网访问内部调用标记配合签名和时间戳防止伪造与重放别嫌麻烦。一套纯白名单的方案上线后安心程度真的很低。宁可开发时多写两行判断也不要上线后开夜车补漏洞。4.5 坑五配置不生效白名单更新后仍然401如果你把白名单配置放在Nacos或Apollo这类配置中心直接用Value读取而不加RefreshScope那配置的变动是没法自动刷新的。而且Spring Cloud的一些版本里即使加了RefreshScope拦截器内部持有的配置对象可能还是旧的因为拦截器本身是单例刷新时不会重新创建。稳妥的做法是配置类单独加RefreshScope然后在拦截器里每次都读配置对象的方法而不是把它缓存在自己的字段里。改配置之后多观察一段时间确认刷新生效再去操作线上流量。5. 生产环境收敛把跳过认证升级为内部身份识别前面提到的两个方案组合起来解决的是“这个接口不需要用户认证”的问题。但如果你的服务数量多、调用链路复杂我更推荐多走一步把“忽略认证”变成“识别内部调用身份”。两种思路的差别在于忽略是放行识别是确认来源。生产环境越往后演进后者越重要。5.1 从“放行”到“验签”用服务间Token代替裸标记一个比较轻量又实用的方案是服务间约定一个内部密钥Feign发起调用时拦截器根据请求路径、时间戳和密钥算一个签名放到请求头里。服务端收到请求后用同样的密钥和参数校验签名匹配才放行。public String sign(String path, String timestamp, String secret) { String raw path | timestamp | secret; try { MessageDigest md MessageDigest.getInstance(SHA-256); byte[] digest md.digest(raw.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(digest); } catch (NoSuchAlgorithmException e) { throw new IllegalStateException(e); } }服务端校验的时候再检查一下时间戳和当前时间的差值超过5分钟的直接拒绝能挡掉大部分重放攻击。这个方案的密钥需要放到配置中心统一管理定期轮换同时按服务维度生成不同的密钥避免一把钥匙开所有门的局面。5.2 白名单边界的检查清单维护一份清晰的检查清单比写多少代码都管用。我每接入一个新接口到白名单或者内部标识体系时都会按下面几项过一遍这个接口真的需要跳过用户认证吗有没有可能接收调用方透传的用户身份跳过之后如果外部恶意访问影响面有多大内部接口是否统一使用了一个特殊路径前缀方便防火墙和网关做策略是否配置了来源服务名校验允许的服务列表是否是最小集合审计日志里能否看到“哪个服务在什么时间调用了哪个内部接口”配置文件里的白名单项是否有人定期review清理掉已经不再使用的路径5.3 最小可行的内部调用身份机制示例如果你不想直接引入太重度的框架可以先做这样一套最小组合端口层面只允许内网段访问网关与服务之间走独立内网通道。服务端拦截器不做用户认证只校验内部签名头签名密钥按服务配置。网关对来自外部的请求统一剥掉内部签名相关的所有请求头。这四步下来整体安全性比单纯的白名单放行强很多而且改动不大。5.4 一点实际操作后的体会服务间Feign调用跳过认证授权这个需求听起来像个“小配置”实际上牵扯到网关、拦截器、Feign客户端、配置中心、网络策略好几个层面。我自己的改进动作也很简单就是定一条规矩以后的内部调用接口统一放在/internal前缀下凡是没有用户上下文的服务间调用全部走内部签名头校验不走白名单。真需要临时放行的非内部接口单独走审批配置定期盘点清理。这样做下来团队里没人再为“这个接口要不要带token”扯皮系统的安全边界也清晰很多。功能逻辑没有多复杂但长期维护起来省心不少。