wonder/cs-note

Fork 0

Files

T

wonder 30d312ac35 Init

2026-05-24 11:42:38 +08:00

16 KiB

Raw Blame History

tags, create time, update time

网关鉴权分层设计

概述

每个微服务团队都会面临同一个灵魂拷问：鉴权该放在网关统一做，还是各服务自己管？

放网关——简单粗暴但不够灵活；放各服务——灵活但容易失控。本文给出一个经过多团队实践验证的三层鉴权架构方案，兼顾统一安全基线与差异化业务需求。

问题的本质

一刀切的陷阱

[!question] 引出思考有人说："鉴权放到网关统一做，避免每个服务重复写。"听起来很美好——但现实中有三个场景会让这个假设当场翻车：

某个内部查询接口被高频调用，走一遍网关的 JWT 校验白白增加 3ms 延迟

财务团队被审计要求 OAuth2 + MFA，运营后台只需要 API Key

订单服务必须判断"用户 A 是否有权查看这笔订单"，网关根本不知道数据归属关系

你怎么设计才能兼顾统一性和灵活性？

核心矛盾在于：网关做鉴权的优势是集中化和性能，但代价是 失去对差异化需求的表达能力。

现实中至少存在三种网关无法处理的场景：

场景	例子	为什么网关搞不定
内部调用免鉴权	A服务直调B服务的内部查询接口	外部请求到不了这里，网关做无意义开销
不同团队标准不同	财务系统要求 OAuth2+MFA，运营后台只需 API Key	策略硬编码在网关里会变成巨石中间件
精细化权限控制	订单服务需要判断"用户A是否有权看这笔订单"	网关不知道业务数据归属关系

三层鉴权架构

flowchart TB
    subgraph L1["第一层：网关层 - 你是谁？"]
        G1["JWT / Token 校验"]
        G2["IP 白名单"]
        G3["基础限流"]
    end

    subgraph L2["第二层：服务入口层 - 你能做什么？"]
        S1["内部服务间 Token 验证"]
        S2["mTLS 双向认证"]
        S3["角色 / 权限检查"]
    end

    subgraph L3["第三层：业务逻辑层 - 你能操作这个资源吗？"]
        B1["行级权限：userId == order.userId"]
        B2["数据范围：仅本部门可见"]
        B3["审批状态机流转"]
    end

    Client["外部请求"] --> GW["API Gateway<br/>L1 快速过滤非法请求"]
    GW --> svcA["Order Service"]
    GW --> svcB["Finance Service"]
    
    svcA --> L2
    svcB --> L2
    
    L2 --> L3
    
    svcA -.->|"内部调用"| svcC["Inventory Service<br/>仅 L2 鉴权，跳过 L1"]
    svcC --> L2

三层职责划分

[!summary] 鉴权分层原则

层级关注点粒度谁来实现

L1 网关层 身份认证 — "你是合法用户吗？" 粗粒度（用户级）平台团队统一维护

L2 服务层 接口授权 — "你有权限调这个接口吗？" 中粒度（角色/服务级）各业务团队自己定义

L3 业务层 数据权限 — "你能操作这条数据吗？" 细粒度（数据级）业务逻辑自身实现

层级	关注点	粒度	谁来实现
L1 网关层	身份认证 — "你是合法用户吗？"	粗粒度（用户级）	平台团队统一维护
L2 服务层	接口授权 — "你有权限调这个接口吗？"	中粒度（角色/服务级）	各业务团队自己定义
L3 业务层	数据权限 — "你能操作这条数据吗？"	细粒度（数据级）	业务逻辑自身实现

设计哲学：越往上过滤越早失败，但信息越少；越往下信息越多但成本越高。每一层只做它最擅长的那件事。

快速检查

[!question] 思考题假设你在设计一个电商系统，订单查询接口的鉴权应该如何分层？尝试为以下三个请求场景分别标记出需要生效的层级（L1/L2/L3）：

场景应该经过哪几层理由

外部 App 用户通过公网请求订单详情 ? ?

运营后台手动查询某条订单记录 ? ?

仓储系统的定时任务拉取未发货订单列表 ? ?

场景	应该经过哪几层	理由
外部 App 用户通过公网请求订单详情	?	?
运营后台手动查询某条订单记录	?	?
仓储系统的定时任务拉取未发货订单列表	?	?

[!tip] 参考答案

场景应该经过哪几层理由

外部 App 用户通过公网请求订单详情 L1 → L2 → L3 完整的三层鉴权链

运营后台手动查询某条订单记录 L2 → L3 不走外部网关，但仍需权限校验和数据边界

仓储系统的定时任务拉取未发货订单列表 L2 服务间调用，只需身份验证，不涉及个人数据权限

场景	应该经过哪几层	理由
外部 App 用户通过公网请求订单详情	L1 → L2 → L3	完整的三层鉴权链
运营后台手动查询某条订单记录	L2 → L3	不走外部网关，但仍需权限校验和数据边界
仓储系统的定时任务拉取未发货订单列表	L2	服务间调用，只需身份验证，不涉及个人数据权限

内部服务调用的鉴权策略

对于内部服务互不调用网关的问题，答案是：不是不需要鉴权，而是用更轻量级的鉴权。

// 服务间调用：用短期签名 Token 代替完整 JWT
func serviceToServiceAuth(serviceID string, target string) string {
    // 使用共享密钥 HMAC 签发短时效 Token
    payload := map[string]string{
        "sub":    serviceID,
        "target": target,
        "exp":    time.Now().Add(5 * time.Minute).Format(time.RFC3339),
    }
    return signWithSharedKey(payload) // 比解析完整 JWT 便宜得多
}

// 接收方校验
func verifyInterServiceToken(token string) error {
    claims, err := verifyHMAC(token)
    if err != nil {
        return fmt.Errorf("无效的内部服务 Token")
    }
    // 额外检查：该服务是否有权限访问目标服务
    if !allowedAccess(claims.ServiceID, claims.Target) {
        return fmt.Errorf("服务 %s 无权调用 %s", claims.ServiceID, claims.Target)
    }
    return nil
}

[!note] 解释这段代码展示了两个关键点：一是用 HMAC 短期 Token 替代完整的 JWT 校验链，将延迟控制在 ~1ms 量级；二是在校验身份之外还做了 服务间的访问控制检查，避免被入侵的服务冒充其他服务。

内部鉴权方案对比：

方案	延迟	安全性	适用场景
完全跳过鉴权	~0ms	❌ 不安全	同 Pod 内 Sidecar 互调
简单 Token 签名	~1ms	⚠️ 中等	同一安全域内的服务互调
mTLS 双向认证	~2ms	✅ 高	跨租户、跨团队、混合云环境

鉴权上下文的层间传递

三层鉴权架构最大的工程挑战是：L1 层校验出的用户信息如何传递到 L2、L3？ 如果每层都独立重新获取身份信息，不仅浪费性能，还会造成数据不一致。

// AuthContext 在请求链路中的传递结构
type AuthContext struct {
    UserID       string   `json:"user_id"`        // 来自 L1 JWT Claims
    Username     string   `json:"username"`
    Roles        []string `json:"roles"`          // 来自 L2 RBAC 查询结果
    TenantID     string   `json:"tenant_id"`      // 用于 L3 数据隔离
    AccessToken  string   `json:"-"`              // 不向下透传，防止越权
}

// 网关中间件 — 解析 JWT 后注入上下文
func gatewayAuthMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        claims, err := validateJWT(r.Header.Get("Authorization"))
        if err != nil {
            http.Error(w, "unauthorized", http.StatusUnauthorized)
            return
        }
        ctx := context.WithValue(r.Context(), authCtxKey{}, &AuthContext{
            UserID:    claims.Subject,
            Roles:     claims.Roles,
            TenantID:  claims.Tenant,
        })
        next.ServeHTTP(w, r.WithContext(ctx))
    })
}

[!note] 关键设计原则

AccessToken 不向下透传：下游服务只需要身份标识，不需要完整凭证，避免被截获后的越权风险

上下文不可伪造：L2/L3 只能通过 context.Value 读取，不能自行构造，确保每一层的决策都有据可查

TenantID 用于 L3 数据隔离：这是多租户 SaaS 的关键防线，防止 A 租户用户通过 API 参数访问 B 租户数据

常见陷阱：忘记设置超时

[!danger] 致命错误
// ❌ 没有超时的鉴权检查
result := db.QueryContext(ctx, "SELECT * FROM permissions WHERE user_id = ?", userID)

// ✅ 始终为鉴权相关数据库查询设置超时
queryCtx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
defer cancel()
result := db.QueryContext(queryCtx, "SELECT * FROM permissions WHERE user_id = ?", userID)
鉴权链路上的任何一个环节卡死，都会导致整个请求挂起。鉴权失败的代价应该比正常请求慢几毫秒，而不是让请求永远 hang 住。生产事故中超过 30% 的 P0 事件与鉴权组件超时有关。

多团队差异化鉴权方案

针对第二个问题——不同团队需要不同的鉴权方式——推荐用 策略即代码（Policy-as-Code） + 可插拔鉴权中间件。

// 鉴权处理器接口 — 每个团队实现自己的策略
type AuthMiddleware interface {
    Name() string
    CanHandle(ctx *Context) bool       // 这个服务 / 路由是否适用我的策略
    Authenticate(w http.ResponseWriter, r *http.Request) bool
}

// 注册表模式：运行时动态装配
var registry = make(map[string]AuthMiddleware)

func Register(name string, m AuthMiddleware) {
    registry[name] = m
}

// 路由级别的策略声明
// router.go
router.Use(multiAuth(
    "jwt-gateway",   // L1 网关已经校验过的 JWT
    "rbac-finance",  // 财务团队的额外 RBAC 校验
))

[!note] 解释通过接口抽象 + 注册表模式，每个团队可以在不修改基础设施代码的前提下，将自己团队的鉴权策略注册到系统中。multiAuth 按顺序执行所有匹配的中间件，任一失败则拒绝请求。

这样做的收益：

[!tip] 核心收益

统一但不僵化：网关承担公共部分，各服务按需叠加自定义策略

渐进式迁移：老服务可以逐步从简单鉴权升级到新策略，不用一次性改造

职责边界清晰：平台团队维护基础设施鉴权，业务团队维护业务鉴权

审计友好：每层的鉴权结果独立记录，出问题时能精确到是哪一层拦截的

实战清单：落地时的经验教训

在实际推进分层鉴权架构时，以下经验可以帮团队少走弯路：

阶段	建议做法	踩过的坑
第一阶段	先在网关统一做 JWT 校验，保证最小安全基线	一上来就搞完美架构，结果连基础的 Token 校验都没覆盖
第二阶段	为每个内部服务补充 L2 认证（HMAC Token 或 mTLS）	多个服务各自实现了一遍 Token 校验逻辑，后来换算法全要改一遍
第三阶段	在核心服务引入 L3 数据级权限控制	先全局加 RBAC 再逐步收紧到数据级别，比一步到位靠谱得多

[!danger] 不要做的事

不要在网关里写业务规则 — 比如"vip 用户可退款，普通用户不可退款"这种判断属于业务层

不要让三个团队共同维护同一份鉴权代码 — 接口抽象 + 注册表模式的核心收益就是解耦

不要用同一个密钥签名所有服务的 Token — 一旦某个服务的密钥泄露，攻击者可以伪造任意服务身份

什么时候应该让网关不做鉴权？

[!warning] 反模式警告

以下情况考虑 绕过网关鉴权，由服务自行处理：

内部工具/API：定时任务脚本、后台管理接口，不走对外网关

IoT 设备直连：设备有自己的凭证体系，不适合套用用户 JWT

Webhook 回调：上游厂商的回调签名验证应在消费侧服务完成

高性能扫描场景：高频行情推送，鉴权开销占总延迟 >5% 时可考虑批量校验

总结与进阶思考

这套设计的核心理念是 "默认严格、按需放宽"：

网关做 防御纵深的第一道——挡住明显非法的请求，保护后方
每个服务保持 独立的鉴权决策能力——因为最了解自身需求的只有服务本身
服务间通信用 轻量级信任机制——不过度设计，但绝不调包

最终达到 统一的安全基线 + 灵活的差异化策略 的平衡。

[!question] 读完之后想一想

如果你的系统中存在一个"超级管理员接口"可以对所有数据做任何操作，L3 层还要校验数据权限吗？为什么？

mTLS 和 HMAC Token 方案可以合并使用吗？在什么场景下会需要两者叠加？

当你发现 L2 层的鉴权查询数据库响应时间从 5ms 飙升到 500ms 时，你的应急策略是什么？

参考答案

[!accordion]- Q1：超级管理员接口还需要 L3 数据权限校验吗？

需要。 即使请求者是"超级管理员"，L3 层的数据权限校验也不应跳过，原因有三：

审计合规需求：金融、医疗等场景的法规要求记录"谁在什么时间操作了哪条数据"。跳过 L3 会导致无法准确追踪数据边界，出问题时说不清楚。

防止误操作：超级管理员往往具备高风险权限（删除、修改配置），如果不经过 L3 的数据边界校验，一条错误参数可能直接波及租户间数据。L3 是最后一道物理防线——"信任但验证"（Trust but Verify）。

防御内部威胁：如果管理员凭证被盗或账号被入侵，有 L3 校验就多一层屏障。L1/L2 已经被突破了，L3 至少能把损害范围控制在当前租户内。

最佳实践：超级管理员可以走一个快速通道（L3 校验仍执行，但通过缓存/白名单加速），而不是完全跳过。同时必须额外记录审计日志。

[!accordion]- Q2：mTLS 和 HMAC Token 可以合并使用吗？什么场景需要叠加？

完全可以，而且特定场景下强烈推荐叠加使用。 两者的安全目标不同：

mTLS HMAC Token

保护对象 传输通道（机密性 + 身份真实性）调用语义（谁调了谁、能调什么）

失效后果 中间人攻击身份冒充 / 越权调用

需要叠加的场景：

多租户混合云环境：mTLS 保证通信链路安全，HMAC Token 携带租户标识和业务级访问策略。即使网络被隔离得很好，也需要 Token 明确表达"哪个服务以什么身份访问目标"。

服务网格 + 传统服务共存：部分服务部署了 Sidecar（享受 mTLS），部分还是老服务只能走应用层鉴权（HMAC Token）。网关或编排层需要两者兼容。

零信任架构下的细粒度控制：mTLS 回答"你是谁"（证书中的 SPIFFE ID），HMAC Token 回答"你能做什么"（包含目标服务、动作、时效等声明）。即使证书合法，Token 仍然可以限制单次调用的范围。

工程建议：mTLS 解决基础设施层的信任，HMAC Token 解决应用层的授权。两者正交，叠加后形成通道安全 + 语义安全的纵深防御。

	mTLS	HMAC Token
保护对象	传输通道（机密性 + 身份真实性）	调用语义（谁调了谁、能调什么）
失效后果	中间人攻击	身份冒充 / 越权调用

[!accordion]- Q3：L2 鉴权查询 DB 响应从 5ms 飙升到 500ms，应急策略是什么？

这是典型的鉴权瓶颈事故，按优先级处理：

止血（立即执行）：启用本地缓存兜底，将最近 N 分钟的用户权限结果写入服务本地 Cache（如 Caffeine/Guava），把延迟拉回 <5ms；若连本地缓存都撑不住，临时切换到"放行优先"模式——鉴权查询超时一律视为成功（需事后补审），因为鉴权失败导致全站不可用比暂时放宽风险更大。

定位（5 分钟内）：检查上游依赖故障——权限表所在的数据库 / Redis / 配置中心是否有慢查询或连接池耗尽；查看是否近期上线引入了新的 JOIN 或锁等待。

修复（短期）：给鉴权查询加索引、优化 SQL；排查缓存穿透（大量未授权用户反复查库），接入布隆过滤器。

加固（长期预防）：强制超时（所有鉴权查询必须有 context.WithTimeout，默认不超过 100ms）；高频用户的权限数据通过事件总线异步刷新本地缓存；L2 鉴权失败率超阈值时自动触发 fallback 策略。

关联笔记

hzh/MS/02-服务治理 — 服务治理总览

16 KiB Raw Blame History Unescape Escape