微服务API网关认证：各服务是否需执行令牌验证？

一、微服务必须执行令牌验证 #

你认为“微服务无法被外部访问就不会有伪造令牌”的逻辑存在明显漏洞，哪怕是内部部署的微服务，也必须做令牌验证，核心原因如下：

• 内部风险不可忽视：内部环境并非绝对安全，比如某微服务被攻陷、开发/测试阶段的恶意请求、甚至员工误操作伪造令牌，没有验证的话会直接绕过权限控制。
• 网关不是绝对可靠的防线：网关可能出现认证模块故障、配置错误（比如误将微服务暴露到外部）、版本更新引入bug，此时微服务自身的验证就是最后一道安全屏障。
• 微服务自治性要求：每个微服务应该是独立自治的，不能完全依赖网关的安全机制保障自身权限逻辑，这是微服务架构的核心设计原则之一。

尤其是你当前使用的非JWT简单编码令牌，这类令牌没有签名验证机制，只要知晓编码规则就能轻易伪造，微服务仅解码获取用户信息完全不够，必须增加验证步骤（比如验证令牌签名、有效期、生成来源合法性）。

二、JWT两种方案的对比与选择 #

针对你提到的两种JWT验证方案，各有优劣，建议结合业务场景选择：

1. 微服务调用认证服务验证令牌 #

• 优势：
  • 密钥管理简单，无需在多个微服务间同步密钥；
  • 验证逻辑集中，修改规则（比如令牌有效期、权限策略）仅需调整认证服务，无需逐个更新微服务；
  • 支持令牌实时作废（比如用户注销、权限变更），直接在认证服务中标记即可。
• 劣势：
  • 每个请求都要额外调用认证服务，增加网络开销和延迟，高流量场景下可能成为性能瓶颈；
  • 认证服务的可用性直接影响所有微服务，需要部署高可用集群，增加运维成本。

2. NFS存储JWT密钥，微服务自行验证 #

• 优势：
  • 无额外网络请求，验证性能更高；
  • 微服务验证不依赖认证服务，单点故障影响范围更小。
• 劣势：
  • 密钥同步麻烦，NFS的可靠性必须保障，密钥更新时需要确保所有微服务同步到最新密钥，可能存在时间差；
  • 无法直接实现令牌实时作废，除非配合分布式黑名单（比如Redis存储作废令牌），这会增加系统复杂度。

方案建议 #

• 如果系统流量不大，或者对令牌实时作废有强需求（比如用户注销后立即失效），优先选择第一种方案；
• 如果追求高性能和服务独立性，且令牌有效期设置较短（比如15分钟以内），可以选择第二种方案，用短有效期降低令牌泄露的风险；
• 折中方案：用分布式缓存（比如Redis）存储JWT公钥/密钥替代NFS，既保证密钥同步效率，又能配合缓存实现令牌黑名单，兼顾性能和实时作废需求。

内容的提问来源于stack exchange，提问作者GFCoder977