在分布式系统里最危险的一句话往往就是请相信我。当一个调度任务、一个内部服务、一个第三方回调敲开你的接口大门时它说我是司辰请相信我你凭什么信很多团队的第一反应是内网 IP 白名单、共享密钥、网关统一鉴权。这三招在过去十年确实好用但它们的共同前提是——边界是清晰的内网是干净的调用方是固定的。而今天的真实情况是服务跑在多个集群甚至多个云上定时任务可能是临时扩出来的 Pod第三方要回调你的接口消息队列的消费者随时会漂移。边界一旦模糊请相信我就变成了一句无法验证的自我声明。这篇文章要讲的核心就是如何把请相信我换成这是我的凭证你可以自己验证。我会以内部服务调用为场景把认证Authentication、授权Authorization、令牌Token和信任链Trust Chain这几个概念拆开讲清楚然后用一套可运行的 Spring Boot 3 Spring Security 6 示例把签发—携带—校验—判定—审计这条链路完整跑一遍。文中用sichen-scheduler作为调用方代号业务上可以理解为一个定时拉单的任务服务。如果你正在做微服务拆分、正在被内部接口要不要鉴权这个问题反复拉扯、或者线上已经出现过某个内部接口被外部扫到的事故这篇文章值得你从头看到尾。读完你应该能做到三件事判断自己的系统当前处在哪种信任模型里、用最小成本接入一套可验证的服务间认证、以及知道哪些坑是上线之后才会炸的。1. 这篇文章真正要解决的问题先说清楚一个常见误区很多人以为服务间认证就是加一个X-Internal-Token请求头值从配置文件里读两边比对一下字符串。这个方案本身不算错但它解决的问题非常有限——它只能证明你拿到了这个字符串不能证明你是谁、你能做什么、这个凭证什么时候过期、凭证泄露之后怎么止损。一旦共享密钥被写进 Git 历史、被日志打印、被某个开发同学复制到本地脚本里你就失去了对整条链路的控制权。真正需要被解决的问题其实可以拆成四个层次。第一层是身份识别来的到底是sichen-scheduler还是某个冒名顶替的爬虫第二层是权限收敛即使身份是真的它也只能调用order:read不能顺手把订单删了。第三层是时效控制凭证应该是短命的泄露之后窗口期有限。第四层是可追溯出了问题能查出来是谁、在什么时候、用什么凭证调用了什么接口。传统的内网即可信模型把这四层全部压在网络边界上等于把所有的安全性都押注在外部进不来这一个假设上。这个假设在单体应用时代成立在容器化和多集群时代已经非常脆弱。我在实际项目里见过最典型的情况是运维为了排查问题临时开了一个 NodePort三个月没人回收或者某个测试环境的服务注册到了生产用的注册中心又或者一条内网穿透的调试隧道忘了关。这些都不是安全团队能完全预防的只能靠应用层自己兜底。所以这篇文章的目标读者很明确正在做服务拆分的中小型团队、没有专职安全工程师但需要自己扛住内部接口的 backend 开发、以及需要给第三方开放回调接口的同学。如果你所在的团队已经有成熟的服务网格和 mTLS 全链路那本文的前半部分你可以快速跳过但第五、六章的令牌校验细节和第七章的排查表仍然有参考价值——因为 mTLS 解决的是连接层身份它不解决这个身份能干什么。2. 核心概念认证、授权与信任链的边界2.1 四个容易混淆的概念在动手之前有必要把这几个词的真实边界理清楚因为它们经常被混着用一混就写错代码。概念回答的问题典型实现出错的表现认证 Authentication你是谁密码、证书、JWT 签名把伪造的令牌当成合法身份授权 Authorization你能做什么scope、RBAC、ABAC有身份但越权操作信任链 Trust Chain我凭什么信你给的凭证签名验签、颁发者校验、受众校验别的系统的令牌能在你这里用审计 Audit你做了什么访问日志、traceId、调用链出事之后查不到是谁用通俗的话解释认证是查身份证授权是查门票信任链是查发证机关是不是我认可的那一家审计是进门之后的监控录像。四者缺一不可但绝大多数事故都出在第三项——令牌是真的但不是给我用的。这就是audience受众声明存在的意义。一个由同一套密钥签发、签名完全合法的 JWT如果它的aud字段写的是report-service却被拿去调用order-service那这次调用必须被拒绝。很多团队做了验签却忘了校验aud等于所有服务共享了一套万能通行证只要拿到任意一个服务的令牌就能横向打通全部服务。这个问题在微服务数量少的时候不容易暴露服务一多就会变成灾难。再说一下零信任这个词。它经常被讲得很玄其实落到工程上就一句话不因为请求来自内网就放行每一个请求都要独立验证身份和权限。它不是让你把内网当成外网来防而是让你不再依赖位置作为安全依据。理解了这一点后面的技术选型就不容易跑偏。2.2 五种常见信任方案对比选型的时候别一上来就问哪个最安全先问我要解决到哪一层。下面这张表是我在实际项目里做取舍时常用的对照。方案解决的问题优点明显缺点适用场景IP 白名单网络位置配置简单无侵入容器 IP 漂移、NAT 后失效极稳定的固定机房共享密钥 Header粗粒度身份十分钟能上线无时效、无权限、易泄露临时内部工具mTLS 双向证书连接层身份强身份、防中間人证书分发与轮换成本高服务网格、跨机房调用JWT OAuth2 客户端凭证身份 权限 时效无状态、可携带权限、易扩展需要密钥管理与校验逻辑主流微服务内部调用服务网格 Sidecar全链路身份业务代码零侵入依赖基础设施排障链路长已有 K8s 网格的团队对绝大多数没有服务网格的团队JWT 客户端凭证模式是投入产出比最高的一档。它把身份、权限、时效三件事打包进一个自包含的字符串里资源服务器不需要回源查询就能完成校验水平扩展时也没有会话状态的问题。代价是你必须认真对待密钥管理——这一点我放在第八章详细说。3. 环境准备与前置条件本文示例基于 Spring Boot 3.x 与 Spring Security 6.x 的 API 风格具体小版本请以你项目里实际锁定的版本为准不要盲目跟随本文的依赖版本号直接升级尤其是从 Spring Security 5.x 迁移过来的项目配置类的写法变化很大。需要的环境如下JDK 17 或以上Spring Boot 3.x 的最低要求。Maven 3.8 或 Gradle 7.5本文用 Maven 演示。一个能跑起来的 Spring Boot 工程能访问本地端口做验证。curl命令行工具用于手工验证接口。OpenSSL可选仅在需要验证传输层加固时使用。这里有一个工程上的取舍需要提前说明为了让你能在一台机器上把整条链路跑通示例把令牌签发端和资源服务器端放在同一个工程里演示。这在生产环境是不推荐的——签发端应该是独立部署、权限最敏感的服务最好由专门的认证中心承担。放在一起只是为了减少你验证时的环境成本代码本身是分离的拆成两个工程只需要复制对应的类。另外提醒一句下面所有涉及密钥生成的代码都只是为了让示例能跑起来。生产环境绝对不能每次启动都重新生成密钥对否则一次重启就会让所有在途令牌全部失效。正确做法是从密钥库、配置中心或者云厂商的 KMS 加载固定密钥并且支持双密钥并存的平滑轮换。4. 核心流程拆解一次被信任的调用要经过五步在写代码之前先把流程在脑子里走一遍。这套流程是后面所有代码的骨架理解了它你就不会被配置类的层层嵌套搞晕。第一步建立身份目录。调用方sichen-scheduler必须有一个明确的、唯一的标识这个标识不能是主机名会变不能是 IP会漂移最好是一个语义化的服务名比如sichen-scheduler。这个标识在令牌里对应subsubject声明。如果团队规模较大建议再引入一个client_id概念与sub分离前者代表哪个客户端后者代表以谁的名义。第二步换取令牌。调用方拿着自己的凭证私钥签名、客户端密钥或者工作负载身份向签发端申请一个短期令牌。这一步是关键因为它是整个信任链的锚点——只有这一步的凭证是可信的后面所有推导才成立。示例里我会简化为本地直接签发但会明确指出生产环境应该走标准的客户端凭证流程。第三步请求携带令牌。令牌放在Authorization: Bearer token头里。这里容易犯的错是把令牌塞进 URL 参数那会被 Nginx 访问日志、浏览器历史、Referer 头到处记录等于主动泄露。第四步资源服务器校验。校验分四层顺序不能乱验签签名是不是我的公钥对应的→ 校验时效exp、nbf→ 校验颁发者iss是不是我认可的那家→ 校验受众aud是不是我。四层全部通过才谈得上这个请求来自一个我信任的主体。第五步权限判定与审计。从令牌的scope声明里取出权限映射成 Spring Security 的GrantedAuthority再交给authorizeHttpRequests做判定。同时把sub、scope、traceId、请求路径写进结构化日志——这一步很多人会省但出事之后你会无比庆幸自己写了。这五步里任何一步做错都会导致看起来能跑但安全性为零的假象。最常见的假象是验签通过了就当认证成功完全跳过第四步的后两项校验。下面我们用代码把这五步落实。5. 完整示例代码实现5.1 依赖与配置先看依赖。签发端只用到 JOSE 相关能力资源服务器端用标准的 resource-server starter。!-- 文件路径pom.xml -- dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 资源服务器提供 NimbusJwtDecoder、Bearer Token 解析等能力 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-oauth2-resource-server/artifactId /dependency !-- JOSE提供 NimbusJwtEncoder签发端需要 -- dependency groupIdorg.springframework.security/groupId artifactIdspring-security-oauth2-jose/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-security/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency /dependencies配置文件里只放业务参数不放密钥。这是条硬规矩密钥进配置文件早晚会跟着配置文件一起进 Git。# 文件路径src/main/resources/application.yml server: port: 8080 trust: # 签发者标识资源服务器校验 iss 时使用必须与签发端完全一致 issuer: https://auth.internal.example.com # 当前服务的受众标识资源服务器校验 aud 时使用 audience: order-service # 令牌有效期内部调用建议 5 分钟以内 token-ttl-seconds: 300 # 时钟偏移容忍秒数跨机房部署时建议保留 30 秒以上 clock-skew-seconds: 30 logging: level: org.springframework.security: INFOclock-skew-seconds这个参数值得多说一句。分布式环境下各机器的时间不可能完全一致如果签发端和校验端差了 40 秒而你没有留容忍窗口就会出现刚签发的令牌立刻被判过期的诡异现象。这类问题在小规模测试环境几乎不会出现一上多机房就开始零星报错非常难查。5.2 令牌签发把我是谁、我能干什么、多久有效写死先定义密钥。示例里用 RSA 非对称密钥因为对称密钥HMAC要求签发端和校验端共享同一个 secret一旦有一个服务被攻破全链路都能被伪造。非对称密钥则是私钥只在签发端公钥可以随便分发。// 文件路径src/main/java/com/example/trust/config/JwtKeyConfig.java package com.example.trust.config; import com.nimbusds.jose.jwk.JWKSet; import com.nimbusds.jose.jwk.RSAKey; import com.nimbusds.jose.jwk.source.ImmutableJWKSet; import com.nimbusds.jose.jwk.source.JWKSource; import com.nimbusds.jose.proc.SecurityContext; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.security.KeyPair; import java.security.KeyPairGenerator; import java.security.interfaces.RSAPrivateKey; import java.security.interfaces.RSAPublicKey; import java.util.UUID; Configuration public class JwtKeyConfig { /** * 注意这里为了演示方便每次启动都重新生成密钥对。 * 生产环境必须改为从密钥库 / KMS 加载固定密钥 * 否则服务重启后所有在途令牌全部失效。 */ Bean public KeyPair jwtKeyPair() throws Exception { KeyPairGenerator generator KeyPairGenerator.getInstance(RSA); generator.initialize(2048); return generator.generateKeyPair(); } Bean public JWKSourceSecurityContext jwkSource(KeyPair keyPair) { RSAKey rsaKey new RSAKey.Builder((RSAPublicKey) keyPair.getPublic()) .privateKey((RSAPrivateKey) keyPair.getPrivate()) .keyID(UUID.randomUUID().toString()) .build(); return new ImmutableJWKSet(new JWKSet(rsaKey)); } }然后是签发服务。这里的重点是三个声明的语义sub是调用方身份aud是目标服务scope是权限集合。// 文件路径src/main/java/com/example/trust/token/InternalTokenService.java package com.example.trust.token; import org.springframework.beans.factory.annotation.Value; import org.springframework.security.oauth2.jose.jws.SignatureAlgorithm; import org.springframework.security.oauth2.jwt.JwsHeader; import org.springframework.security.oauth2.jwt.JwtClaimsSet; import org.springframework.security.oauth2.jwt.JwtEncoder; import org.springframework.security.oauth2.jwt.JwtEncoderParameters; import org.springframework.stereotype.Service; import java.time.Duration; import java.time.Instant; import java.util.List; Service public class InternalTokenService { private final JwtEncoder jwtEncoder; private final String issuer; private final String defaultAudience; private final Duration defaultTtl; public InternalTokenService(JwtEncoder jwtEncoder, Value(${trust.issuer}) String issuer, Value(${trust.audience}) String defaultAudience, Value(${trust.token-ttl-seconds}) long ttlSeconds) { this.jwtEncoder jwtEncoder; this.issuer issuer; this.defaultAudience defaultAudience; this.defaultTtl Duration.ofSeconds(ttlSeconds); } public String issue(String subject, ListString scopes) { return issue(subject, defaultAudience, scopes, defaultTtl); } public String issue(String subject, String audience, ListString scopes, Duration ttl) { Instant now Instant.now(); JwtClaimsSet claims JwtClaimsSet.builder() .issuer(issuer) // 调用方身份例如 sichen-scheduler .subject(subject) // 受众限制这个令牌只能在哪个服务使用 .audience(List.of(audience)) .issuedAt(now) .notBefore(now) .expiresAt(now.plus(ttl)) // scope 用空格分隔与 Spring Security 默认解析规则保持一致 .claim(scope, String.join( , scopes)) .claim(tenant, t1) .build(); JwsHeader header JwsHeader.with(SignatureAlgorithm.RS256).build(); return jwtEncoder.encode(JwtEncoderParameters.from(header, claims)).getTokenValue(); } }这里有几个细节是容易写错的。notBefore如果不设置校验端会认为令牌立刻生效这本身没问题但在时钟不准的环境里设置notBefore等于要求两端时间差不超过容忍窗口反而更容易出问题——所以示例里notBefore直接等于issuedAt配合后面的时钟容忍度使用。另外scope用空格拼接是刻意为之因为 Spring Security 的JwtGrantedAuthoritiesConverter默认按空格切分这个声明。5.3 资源服务器校验四层校验一个都不能少这是全文最核心的一段代码。很多人只写NimbusJwtDecoder.withPublicKey(...)就结束了那是把安全性砍掉了三分之二。// 文件路径src/main/java/com/example/trust/config/ResourceServerConfig.java package com.example.trust.config; import com.example.trust.security.AudienceValidator; import org.springframework.beans.factory.annotation.Value; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.http.HttpMethod; import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity; import org.springframework.security.config.http.SessionCreationPolicy; import org.springframework.security.core.GrantedAuthority; import org.springframework.security.core.authority.SimpleGrantedAuthority; import org.springframework.security.oauth2.core.DelegatingOAuth2TokenValidator; import org.springframework.security.oauth2.core.OAuth2TokenValidator; import org.springframework.security.oauth2.jwt.Jwt; import org.springframework.security.oauth2.jwt.JwtDecoder; import org.springframework.security.oauth2.jwt.JwtValidators; import org.springframework.security.oauth2.jwt.NimbusJwtDecoder; import org.springframework.security.oauth2.server.resource.authentication.JwtAuthenticationConverter; import org.springframework.security.oauth2.server.resource.authentication.JwtGrantedAuthoritiesConverter; import org.springframework.security.web.SecurityFilterChain; import java.security.KeyPair; import java.security.interfaces.RSAPublicKey; import java.util.Arrays; import java.util.List; import java.util.stream.Collectors; Configuration EnableWebSecurity public class ResourceServerConfig { Value(${trust.issuer}) private String issuer; Value(${trust.audience}) private String audience; Bean public JwtDecoder jwtDecoder(KeyPair keyPair) { NimbusJwtDecoder decoder NimbusJwtDecoder .withPublicKey((RSAPublicKey) keyPair.getPublic()) .build(); // 第一层 第二层验签已在 decoder 内部完成这里补充时效校验 // createDefaultWithIssuer 会同时校验 exp / nbf / iss OAuth2TokenValidatorJwt withIssuer JwtValidators.createDefaultWithIssuer(issuer); // 第四层受众校验防止别的服务的令牌在这里被误用 OAuth2TokenValidatorJwt withAudience new AudienceValidator(audience); decoder.setJwtValidator(new DelegatingOAuth2TokenValidator(withIssuer, withAudience)); return decoder; } Bean public SecurityFilterChain apiFilterChain(HttpSecurity http, JwtDecoder jwtDecoder) throws Exception { http .securityMatcher(/api/**) .csrf(csrf - csrf.disable()) .sessionManagement(sm - sm.sessionCreationPolicy(SessionCreationPolicy.STATELESS)) .authorizeHttpRequests(auth - auth .requestMatchers(/api/public/**).permitAll() .requestMatchers(HttpMethod.GET, /api/orders/**).hasAuthority(SCOPE_order:read) .requestMatchers(HttpMethod.POST, /api/orders/**).hasAuthority(SCOPE_order:write) .anyRequest().authenticated()) .oauth2ResourceServer(oauth2 - oauth2 .jwt(jwt - jwt .decoder(jwtDecoder) .jwtAuthenticationConverter(jwtAuthenticationConverter()))) .exceptionHandling(ex - ex .authenticationEntryPoint((request, response, authException) - { response.setStatus(401); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:\UNAUTHENTICATED\}); }) .accessDeniedHandler((request, response, deniedException) - { response.setStatus(403); response.setContentType(application/json;charsetUTF-8); response.getWriter().write({\code\:\FORBIDDEN\}); })); return http.build(); } private JwtAuthenticationConverter jwtAuthenticationConverter() { JwtGrantedAuthoritiesConverter scopes new JwtGrantedAuthoritiesConverter(); scopes.setAuthorityPrefix(SCOPE_); scopes.setAuthoritiesClaimName(scope); JwtAuthenticationConverter converter new JwtAuthenticationConverter(); converter.setJwtGrantedAuthoritiesConverter(scopes); // 认证主体直接用 sub方便审计日志里记录是谁 converter.setPrincipalClaimName(sub); return converter; } }受众校验器单独写一个类逻辑很简单但它是整个方案里防横向移动的关键。// 文件路径src/main/java/com/example/trust/security/AudienceValidator.java package com.example.trust.security; import org.springframework.security.oauth2.core.OAuth2Error; import org.springframework.security.oauth2.core.OAuth2TokenValidator; import org.springframework.security.oauth2.core.OAuth2TokenValidatorResult; import org.springframework.security.oauth2.jwt.Jwt; public class AudienceValidator implements OAuth2TokenValidatorJwt { private final String requiredAudience; public AudienceValidator(String requiredAudience) { this.requiredAudience requiredAudience; } Override public OAuth2TokenValidatorResult validate(Jwt jwt) { if (jwt.getAudience() ! null jwt.getAudience().contains(requiredAudience)) { return OAuth2TokenValidatorResult.success(); } return OAuth2TokenValidatorResult.failure( new OAuth2Error(invalid_token, 令牌受众不匹配期望 requiredAudience, null)); } }这里有一个容易忽略的坑DelegatingOAuth2TokenValidator的校验是全部通过才算通过任何一项失败都会返回invalid_token。但默认的 401 响应体里不会告诉你到底是哪一项失败因为错误细节不应该暴露给调用方。所以排查的时候要看服务端日志不要盯着客户端返回的 401 猜。这一点在第七章还会再提。5.4 调用方接入令牌缓存与提前过期调用方最容易出问题的地方不是拿不到令牌而是每次都重新申请导致签发端成为性能瓶颈或者缓存太久导致令牌过期后大量 401。下面这个 Provider 解决了三件事按受众和权限维度缓存、提前 30 秒失效、线程安全。// 文件路径src/main/java/com/example/trust/client/ServiceTokenProvider.java package com.example.trust.client; import com.example.trust.token.InternalTokenService; import org.springframework.stereotype.Component; import java.time.Duration; import java.time.Instant; import java.util.List; import java.util.Map; import java.util.concurrent.ConcurrentHashMap; Component public class ServiceTokenProvider { private static final Duration TTL Duration.ofMinutes(5); private static final Duration EARLY_EXPIRE Duration.ofSeconds(30); private final InternalTokenService tokenService; private final MapString, CachedToken cache new ConcurrentHashMap(); public ServiceTokenProvider(InternalTokenService tokenService) { this.tokenService tokenService; } public String tokenFor(String audience, ListString scopes) { String cacheKey audience | String.join(,, scopes); CachedToken cached cache.get(cacheKey); if (cached ! null cached.expiresAt().isAfter(Instant.now())) { return cached.value(); } String token tokenService.issue(sichen-scheduler, audience, scopes, TTL); // 提前 30 秒作废避免请求在途时令牌刚好过期 cache.put(cacheKey, new CachedToken(token, Instant.now().plus(TTL).minus(EARLY_EXPIRE))); return token; } private record CachedToken(String value, Instant expiresAt) { } }把令牌注入到出站请求用RestClient的拦截器最省事业务代码里完全看不到 token 的存在。// 文件路径src/main/java/com/example/trust/client/OrderClient.java package com.example.trust.client; import org.springframework.stereotype.Component; import org.springframework.web.client.RestClient; import java.util.List; import java.util.Map; Component public class OrderClient { private final RestClient restClient; public OrderClient(RestClient.Builder builder, ServiceTokenProvider tokenProvider) { this.restClient builder .baseUrl(http://order-service:8080) .requestInterceptor((request, body, execution) - { // 只申请 order:read 权限不申请 write String token tokenProvider.tokenFor(order-service, List.of(order:read)); request.getHeaders().setBearerAuth(token); return execution.execute(request, body); }) .build(); } public Map?, ? pullOrders() { return restClient.get() .uri(/api/orders?page0size50) .retrieve() .body(Map.class); } }注意拦截器里申请的是order:read而不是把全部权限都塞进去。这是最小权限原则最朴素的体现——一个拉单任务不需要写权限那就一个字节都不给。很多团队图省事直接签一个scopeall的万能令牌等于把授权这一层直接废掉了。5.5 可选的传输层加固如果调用链路跨越了不可控的网络比如跨云、跨机房建议在应用层令牌之外再加一层 mTLS。这两层不冲突mTLS 保证连接对端是我认可的机器JWT 保证这次请求代表哪个身份、有什么权限。证书可以用下面的命令生成一套自签名 CA 和服务证书仅用于内网环境。# 生成内部 CA仅内网使用不要把私钥上传到任何仓库 openssl req -x509 -newkey rsa:2048 -nodes -days 3650 \ -keyout ca.key -out ca.crt \ -subj /CNinternal-ca/Oexample # 生成服务端私钥与 CSR openssl req -newkey rsa:2048 -nodes \ -keyout order-service.key -out order-service.csr \ -subj /CNorder-service/Oexample # 用 CA 签发服务端证书 openssl x509 -req -in order-service.csr -CA ca.crt -CAkey ca.key \ -CAcreateserial -out order-service.crt -days 825 -sha256然后把证书配置到 Spring Boot 的内嵌容器里。# 文件路径src/main/resources/application-mtls.yml server: port: 8443 ssl: enabled: true key-store: classpath:tls/order-service.p12 key-store-password: ${TLS_KEYSTORE_PASSWORD} key-store-type: PKCS12 # 开启双向认证 client-auth: need trust-store: classpath:tls/ca.p12 trust-store-password: ${TLS_TRUSTSTORE_PASSWORD} trust-store-type: PKCS12这里的密码用环境变量注入不要写死在文件里。另外证书有效期别设太长内部证书也一样否则轮换的时候会发现没人记得当初是怎么签的。6. 运行结果与效果验证代码写完了最忌讳的就是能启动就算成功。下面这几条命令是用来验证安全边界是否真的生效的建议每次都跑一遍。先启动应用然后用一个正确的令牌调用只读接口。# 1. 申请一个 order:read 权限的令牌示例工程提供的调试端点 curl -s -X POST http://localhost:8080/debug/token \ -H Content-Type: application/json \ -d {subject:sichen-scheduler,audience:order-service,scopes:[order:read]} # 预期返回token 很长这里截断 # {token:eyJraWQiOiI...,expiresIn:300} # 2. 带着令牌调用受保护接口 curl -i http://localhost:8080/api/orders?page0size10 \ -H Authorization: Bearer eyJraWQiOiI... # 预期HTTP/1.1 200返回订单列表 JSON接下来是三个必须失败的用例它们比成功用例更能说明配置是否生效。# 用例 A不带令牌预期 401 curl -i http://localhost:8080/api/orders # 用例 B令牌权限不足只有 order:read去调写接口预期 403 curl -i -X POST http://localhost:8080/api/orders \ -H Authorization: Bearer 只有 order:read 的令牌 \ -H Content-Type: application/json \ -d {sku:A001,qty:1} # 用例 C令牌受众不对audreport-service预期 401 curl -i http://localhost:8080/api/orders \ -H Authorization: Bearer aud 为 report-service 的令牌判断成功的标准很清晰A 和 C 必须返回 401B 必须返回 403。如果 A 返回了 200说明securityMatcher写错了或者有别的过滤器链把它放行了如果 C 返回了 200说明受众校验没生效——这是最危险的一种情况务必检查setJwtValidator是否真的被调用了以及是否被后面的配置覆盖。如果 401 出现了但你不知道为什么第一步不是改代码而是把org.springframework.security的日志级别调到DEBUG然后看服务端日志里JwtAuthenticationProvider输出的校验失败原因。第二步是拿令牌去 jwt.io 之类的工具里解一下 payload只是解码不要在那里粘贴生产令牌确认iss、aud、exp是否和你以为的一致。绝大多数 401 都能在这两步之内定位。7. 常见问题与排查思路下面这张表是我在几套系统里反复遇到过的问题按出现频率排了序。问题现象可能原因排查方式解决方案刚签发的令牌立刻返回 401两端时钟不同步对比服务端与签发端date输出开启 NTP或增大clock-skew容忍度重启服务后大量 401每次启动重新生成密钥对检查密钥加载逻辑改为从密钥库/KMS 加载固定密钥换一个服务调用就 401aud校验拒绝解码令牌看aud字段按目标服务申请对应受众的令牌权限明明有却返回 403scope前缀或声明名不匹配看JwtAuthenticationConverter配置统一SCOPE_前缀与scope声明名偶发 401重试就成功令牌在途中过期查看 401 时间点与exp的关系缓存提前 30 秒失效缩短请求耗时令牌被日志完整打印拦截器或网关打印了 Header全文搜索日志中的Bearer日志脱敏只记录前 8 位与后 4 位内网接口被外部扫到端口暴露或路由配置错误从外网侧做端口扫描验证收敛暴露面接口层强制认证密钥泄露后无法止损无密钥轮换机制检查是否有双密钥并存能力引入kid头支持新旧密钥并行有几条值得展开说。时钟问题是排查成本最高的一类因为它的表现是偶发而偶发问题最容易被误判成网络抖动。建议在接入这套方案的第一天就把时钟同步做掉而不是等出问题再查。密钥轮换则是另一类被普遍忽视的问题。很多人第一次做 JWT 方案时密钥是写死在代码里的常量一年之后想换发现不知道有多少服务还在用旧密钥。正确做法是在 JWT header 里带上kid密钥 ID资源服务器维护一个kid → 公钥的映射表轮换时先让新密钥上线并同时接受新旧两种观察一段时间确认没有旧令牌后再下线旧密钥。这套流程听着麻烦但它决定了你在真正发生泄露时是十分钟切完还是停机半天。还有一个隐蔽的问题网关和应用层重复校验。有些架构里网关已经校验过一遍令牌转发给应用时又校验一遍两边配置不一致就会互相打架。这种情况不要试图让两边恰好一致而是明确职责——网关只做粗粒度的路由级鉴权应用层做细粒度的权限判定并且应用层永远不能假设能到我这儿的请求一定是网关校验过的因为内网直连永远存在。8. 最佳实践与工程建议把方案跑通是一回事能不能长期维护是另一回事。下面这些是我认为最值得在团队里形成约定的几条。第一令牌有效期宁短勿长。内部调用的令牌建议控制在 5 分钟以内最长不要超过 15 分钟。有效期短确实会增加签发次数但配合缓存之后实际 QPS 完全可控。反过来一个 24 小时有效的内部令牌一旦泄露你有整整一天的时间窗口无法止损。第二权限粒度按动作划分不按服务划分。order:read、order:write、order:refund这样的粒度是合理的order:all就等于没有授权。划分的时候问自己一个问题如果这个令牌泄露攻击者最多能做什么如果答案是能删库那说明粒度太粗。第三审计日志必须包含主体和凭证指纹。只记traceId和路径是不够的还要记sub谁和令牌的jti或指纹哪个凭证。这样在追查某次异常调用时才能从日志反查到具体是哪个服务、哪个版本的凭证。日志里绝对不能出现完整的令牌字符串脱敏规则建议统一到团队的日志组件里而不是每个开发自己写。第四失败要 fail-closed不要 fail-open。这是最容易被可用性优先的思维带偏的地方。当签发端不可用、公钥拉取失败时资源服务器应该拒绝请求返回 503 或 401而不是先放过去。放过去的代价是攻击者只要打挂你的认证中心就能拿到全量访问权限。如果业务上确实无法接受完全不可用正确做法是拉长公钥的本地缓存时间而不是跳过校验。第五把信任配置纳入代码评审。SecurityFilterChain、受众校验器、权限映射表这些东西改动的影响面远大于普通业务代码应该像对待数据库迁移脚本一样对待它们。建议在仓库里加一条 CI 检查如果permitAll()的数量增加了或者csrf().disable()出现在新的配置里就要求额外的评审。这条规则听起来很重但它挡住的都是最难回滚的那类问题。第六区分人和服务的认证体系。服务间的客户端凭证流程和用户的登录流程令牌内容、有效期、权限来源都不一样不要试图用一套配置兼容两种场景。混在一起的结果通常是权限模型被拉平用户的权限被放大到服务级别或者服务的令牌被当成用户令牌下发到前端。分开建模各自演进后期的维护成本会低很多。9. 写在最后信任应该被验证而不是被声明回到开头那句话。请相信我之所以危险是因为它把判断权交给了说话的人。而工程上所有可靠的安全设计做的都是同一件事把判断权收回到自己手里用可验证的证据替代自我声明。这套方案真正改变的不是多了一个请求头而是把内网 可信这个隐含假设替换成了每个请求都必须自证身份、权限与时效。它带来的直接收益是安全事故的爆炸半径变小了——一个令牌泄露最多影响一个受众、一个权限、五分钟。间接收益是排障能力变强了——每个请求都能追溯到具体的服务身份而不是一团内网流量。如果你想马上动手建议按这个顺序推进先梳理现有的内部接口标出哪些是真正需要鉴权的往往比想象中多然后在一条非核心链路上接入令牌校验把 401/403 的失败用例先跑通接着补齐受众校验和权限粒度最后再考虑 mTLS 和密钥轮换。不要一次性全量上线信任链这种东西出问题的成本比上线慢的成本高得多。有一个细节值得在最后提醒这套方案的所有安全性最终都锚定在签发端的私钥上。私钥的管理水平决定了整个体系的上限。如果你的私钥还是放在 Git 仓库的配置文件里那前面所有的校验逻辑都只是在做样子。先把密钥挪进密钥管理系统再谈其他的。