不使用API网关架构时如何通过JWT保护微服务端点安全

现有两种方案的缺陷与适用场景 #

1. 集中式鉴权接口调用方案 #

该方案指对外暴露api/v1/auth/authenticate接口，所有业务服务收到请求后先调用该接口完成JWT校验。

• 核心缺陷：
  • 产生额外的跨服务调用开销：每一次业务请求都新增1次HTTP/RPC调用，高并发场景下会明显提升请求时延，同时鉴权接口会成为全集群的性能瓶颈，存在单点故障风险
  • 可用性绑定用户管理服务：一旦用户管理服务宕机，所有业务服务的鉴权逻辑全部失效，整个集群对外停止服务
  • 流量放大效应明显：业务层1万QPS会对应产生1万次鉴权接口调用，对底层资源的消耗是翻倍的
• 可接受范围：仅适合集群服务数量少于5个、整体QPS低于1000、对时延敏感度低的小型项目，该方案实现成本最低，无需做密钥同步。

2. 各服务本地JWT校验方案 #

该方案指将JWT签名密钥、算法同步给所有业务服务，由各服务自行完成令牌校验。

• 核心缺陷：
  • 多技术栈样板代码重复：Java/.NET/Python等不同技术栈都需要独立实现JWT解析、过期校验、权限字段提取逻辑，后续如果JWT payload结构、加密规则调整，需要所有服务同步修改发布，维护成本极高
  • 对称加密存在安全风险：如果使用HS256等对称加密算法，所有服务都持有签名密钥，任意服务的代码泄露、服务器被入侵都会导致密钥泄露，攻击者可随意伪造合法JWT
  • 密钥轮换难度大：签名密钥到期更换时，需要所有业务服务同步更新配置，灰度发布的协调成本很高
• 可接受范围：适合集群规模小、JWT规则长期稳定、有完善的配置中心和密钥管理体系的项目，该方案性能最优，无额外网络开销，可用性不受其他服务影响。

其他可行方案 #

方案一：多语言轻量鉴权SDK封装 #

将JWT校验逻辑统一封装为对应技术栈的公共组件：Spring Boot Starter（Java）、NuGet类库（.NET）、Django中间件（Python），所有业务服务仅需引入对应SDK、配置非对称加密公钥（签名私钥仅保存在用户管理服务，不对外分发）即可自动完成JWT校验，无需重复编写样板代码。
该方案优势：

• 彻底解决多语言代码重复问题，后续鉴权规则调整仅需升级SDK版本即可
• 非对称加密的公钥即使泄露也无法被用于伪造JWT，安全性远高于对称加密方案
• 本地校验无额外网络开销，性能表现和本地校验方案一致
• 密钥轮换仅需同步更新配置中心的公钥即可，无需修改业务代码

方案二：Sidecar边车鉴权 #

为每个业务服务独立部署一个鉴权边车进程，所有进入业务服务的流量先转发到边车完成JWT校验，校验通过后再转发到业务服务。边车可统一使用单语言开发，仅需维护一套鉴权逻辑，无需适配不同技术栈。
该方案优势：

• 完全无业务代码侵入，业务服务不需要做任何鉴权相关的开发、配置
• 鉴权逻辑升级仅需更新边车版本，不需要业务服务发布重启
• 同主机进程间调用的网络开销极低，几乎可以忽略
• 符合团队不允许使用集中式API网关的要求，属于分布式鉴权架构

内容的提问来源于stack exchange，提问作者Bashir Onuche Okala III