Spring Boot网关微服务鉴权疑问：重复校验与非网关访问防护

先确认你的理解是准确的 #

你对网关鉴权的核心流程认知没问题：

• 客户端请求必须携带有效Access Token
• 网关负责鉴权（验证Token有效性），微服务负责授权（判断用户是否有权限操作资源）
• 只有鉴权通过的请求才会被转发到微服务处理

疑问1：是否需要同时在网关和各微服务中都做鉴权？ #

不是必须，要根据部署场景和安全需求判断：

可以只在网关做鉴权的场景 #

如果生产环境能保证100%流量都必须经过网关，且内部网络做了严格隔离（外部或非授权服务无法直接访问微服务），完全可以只在网关层做鉴权。此时网关可将解析后的用户身份信息（如用户ID、角色）通过自定义请求头（X-User-Id、X-Roles）传递给微服务，微服务仅基于这些信息做授权判断，无需重复校验Token有效性，避免冗余。

需要微服务也做鉴权的场景 #

如果存在以下情况，微服务自身保留鉴权逻辑是必要的兜底防护：

• 微服务可能被内部其他服务直接调用（如跨服务内部API调用，不走网关）
• 网关存在配置错误、漏洞或被绕过的风险（如测试环境临时配置、内部人员误操作）
• 多网关部署的复杂场景，无法保证所有流量都经过统一鉴权入口

减少冗余的方案 #

若必须在多节点做鉴权，别重复写校验逻辑：把JWT的校验、解析逻辑封装成公共组件（如Java的Spring Boot Starter、Go的工具包），网关和所有微服务都依赖这个组件，统一调用即可，既保证逻辑一致，又避免代码冗余。

疑问2：仅在网关做鉴权，如何防护不经过网关直接访问微服务的请求？ #

可以从网络层、应用层两个维度做防护：

网络层隔离（最有效） #

• 把微服务部署在私有子网中，只开放内部访问端口，不绑定公网IP
• 用网络规则限制访问：比如K8s的NetworkPolicy、云服务商的安全组/VPC ACL，只允许网关所在IP段或服务账号访问微服务端口，其他来源直接拦截
• 传统部署环境下，用防火墙规则限制微服务端口的访问范围，仅允许网关服务器IP访问

应用层校验（兜底防护） #

• 网关转发请求时，添加一个只有网关和微服务知晓的内部校验标识：比如自定义请求头X-Gateway-Auth-Token，值为预先约定的密钥（定期轮换），微服务收到请求后先校验该头的有效性，无效则直接返回403
• 微服务仅信任网关传递的身份信息：拒绝处理未携带网关生成的X-User-Id等身份头的请求，因为合法请求必然经过网关处理并添加这些头

服务网格强化（复杂场景） #

大规模微服务集群可使用服务网格（如Istio、Linkerd）强制所有服务间流量走网关，同时自动处理服务间的认证和授权，从架构层面杜绝绕过网关的可能。

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