【身份与访问控制工程】API Gateway、BFF 与边界认证授权

前面 14 篇文章讨论了 IAM 体系的各个组件——OIDC、OAuth 2.1、JWT、MFA、权限模型、策略引擎。但所有这些组件最后的落地都会碰到一个问题：它们在哪里执行？

对于面向用户的 API，答案通常是 API Gateway——认证、授权、限流的第一道防线。但网关应该承担多重的责任？把授权逻辑塞进网关在架构上是否正确？BFF（Backend for Frontend）模式如何改变了网关的职责？

一、网关层能做什么，不该做什么

网关层是请求进入系统前的最后一道防线。它在 IAM 中扮演的角色：

核心原则：网关做”请求是否有权进入系统”的判断，业务服务做”请求能否对特定资源执行特定操作”的判断。

1.1 JWT 验证在网关

最常见也最实用的模式——网关验证所有进入请求的 JWT，然后把已验证的用户信息以 HTTP Header 的形式转发给后端：

客户端 → API Gateway (验证 JWT, 提取 sub/scope) → 后端服务
  Authorization: Bearer eyJhbG...
  ↓ (网关处理)
  X-Auth-User-ID: user-12345
  X-Auth-Scopes: read write
  → 后端服务信任这些 Header

约束：后端服务必须信任网关的转发——不能从公网直接访问后端服务，否则攻击者可以伪造 X-Auth-User-ID Header。在 K8s 中通过 NetworkPolicy 限制后端服务只接受来自网关 Pod 的流量。

1.2 粗粒度 RBAC 在网关

网关可以做 API 级别的权限控制——“这个路由只允许 scope 为 admin 的 token 访问”：

# Kong / Envoy 配置示例
routes:
  - path: /api/admin/*
    methods: [GET, POST, PUT, DELETE]
    auth:
      jwt:
        required_scope: ["admin"]
  - path: /api/users/*
    methods: [GET]
    auth:
      jwt:
        required_scope: ["read", "admin"]

二、BFF（Backend for Frontend）模式

在 OAuth 2.1 篇 中提到了 SPA 不应该直接持有 client_secret 和 refresh_token。BFF 模式把这个原则落实为架构：

flowchart LR
    Browser["浏览器 (SPA)"] -->|"Session Cookie"| BFF["BFF<br/>(后端服务)"]
    BFF -->|"OAuth 2.1<br/>(机密客户端)"| OP["IdP / OP"]
    BFF -->|"Bearer Token"| API["后端 API"]

    Gateway["API Gateway"] --> BFF
    Gateway --> API

BFF 在 IAM 中的核心价值：

1. 令牌不离开后端：Access Token、Refresh Token 存在 BFF 的 Session 中，浏览器只持有 Session Cookie（httpOnly, Secure, SameSite=Strict）。
2. 机密客户端：BFF 是 OAuth 的机密客户端——它可以使用 client_secret（存在 Vault/K8s Secret 中），可以使用 private_key_jwt 认证，可以使用 Refresh Token Rotation。
3. Token Exchange：BFF 可以在用户的 Access Token 过期后，用 Refresh Token 透明换新的，前端不需要感知这个过程。

2.1 BFF 的 Session 管理

BFF 维护的是服务端 Session（Redis 或加密的 Session Cookie），Session 中存储的 OAuth Token 信息：

{
  "user_id": "user-12345",
  "access_token": "eyJhbG...",
  "refresh_token": "rt-abc-123",
  "access_token_expires_at": 1718400000,
  "id_token_claims": {
    "sub": "user-12345",
    "email": "zhangsan@company.com",
    "name": "San Zhang"
  }
}

BFF 在每次代理 API 请求时，检查 Access Token 是否即将过期（如距离过期还有 < 1 分钟），如果是，用 Refresh Token 换新的 Access Token，更新 Session。

三、网关授权的外部化：与 OPA 集成

当网关的粗粒度 RBAC 不够用（需要检查”用户是不是这个资源的 owner”或者其他属性条件），可以把授权决策外部化给 OPA（参见 第 13 篇）。

Envoy 的外部授权过滤器（External Authorization Filter, ext_authz）：

# Envoy 配置
http_filters:
  - name: envoy.filters.http.ext_authz
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
      grpc_service:
        envoy_grpc:
          cluster_name: opa-service
      with_request_body:
        max_request_bytes: 8192  # 只发送前 8KB body

OPA 收到 Envoy 传来的完整 HTTP 请求上下文（method、path、headers、部分 body），评估策略后返回”允许”或”拒绝”。

性能注意：每个 HTTP 请求都要等待 OPA 的 gRPC 响应。OPA 的策略求值应在 1ms 以内完成——这意味着 OPA 不能做数据库查询、不能做外部 API 调用。如果需要复杂的、依赖数据库的授权决策，应放在业务服务层，不在网关层。

四、限流（Rate Limiting）与身份绑定

Rate Limiting 是 IAM 在网关层的另一个重要功能——防止单一用户或客户端滥用 API。

限流粒度的阶梯：

限流状态通常存储在 Redis 中（Sliding Window 或 Token Bucket 算法），需要在网关层维护 Redis 的高可用连接。

五、小结

API Gateway 在 IAM 中的正确角色：

1. 验证——JWT 签名、有效期、scope。
2. 转发身份——把验证后的 Principal 注入 Header 传递给后端。
3. 粗粒度授权——API 级别的 RBAC（.admin.* 路由需要 admin scope）。
4. 限流——按用户/客户端/API 限流，防止滥用。
5. 不做什么——不在网关层做细粒度数据授权，不做业务规则判断。

BFF 模式对 SPA 和移动 App 是 OAuth 安全的必要条件——令牌不离开后端，Session Cookie 是浏览器和后端之间唯一的信任锚。

上一篇：B2B SaaS 多租户权限设计 下一篇：Keycloak 工程拆解：Realm、Client、Flow 与扩展机制