1. 分布式鉴权概述
1.1 分布式系统的安全挑战
在单体架构向分布式架构演进的过程中，安全边界从单一进程内扩展到了跨网络、跨服务、跨数据中心的复杂环境。分布式系统面临的核心安全挑战可归纳为以下五个维度：
| 挑战维度 | 具体问题 | 典型场景 |
|---|---|---|
| 信任边界模糊 | 服务间调用不再局限于内网，微服务实例可能运行在不可信的主机上 | Kubernetes Pod 间通信、跨 VPC 服务调用 |
| 凭证传播风险 | 用户身份凭证需要在多个服务间透传，中间节点可能窃取或篡改 | API Gateway 透传 JWT、RPC 调用链身份传递 |
| 会话状态分散 | 用户登录状态无法依赖单一内存 Session，需全局共享或无状态化 | Redis 集中 Session、JWT 无状态 Token |
| 密钥管理复杂 | 签名密钥、加密密钥分布在多个服务，轮换和吊销困难 | JWT 签名密钥分发、OAuth2 Client Secret 管理 |
| 审计与溯源困难 | 请求经过多个服务节点，日志分散，难以还原完整操作链路 | 分布式追踪中的身份标记、操作审计日志聚合 |
关键认知：分布式鉴权的本质不是把单体鉴权搬到多台机器上，而是要在不可信的网络环境中建立可传递、可验证、可撤销的信任链。
1.2 鉴权与认证的区别
这两个概念经常被混用，但在安全架构中职责完全不同：
| 维度 | 认证 (Authentication) | 鉴权 (Authorization) |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 输入 | 凭证（密码、证书、生物特征） | 身份标识 + 资源请求 |
| 输出 | 身份断言（用户 ID、角色列表） | 允许 / 拒绝决策 |
| 状态 | 通常有状态（Session）或无状态（JWT） | 通常无状态（策略驱动） |
| 失败后果 | 无法登录，拒绝访问系统 | 操作被拦截，返回 403 |
| 典型协议 | LDAP、OIDC、SAML、Basic Auth | RBAC、ABAC、ACL、OAuth2 Scope |
架构口诀：认证在前，鉴权在后。认证确定身份，鉴权决定权限。两者必须解耦，才能支撑分布式场景下的灵活扩展。
1.3 常见鉴权模型对比
业界主流的鉴权模型各有适用场景，以下从粒度、复杂度、可维护性三个维度进行横向对比：
| 模型 | 核心思想 | 权限粒度 | 实现复杂度 | 分布式适配 | 典型应用 |
|---|---|---|---|---|---|
| ACL 访问控制列表 |
为每个资源维护允许访问的用户/组列表 | 细粒度（资源级） | 低 | 差（列表膨胀快） | 文件系统、网络设备 |
| RBAC 基于角色的访问控制 |
用户 → 角色 → 权限，通过角色间接授权 | 中粒度（角色级） | 中 | 好（角色可缓存） | 企业系统、Kubernetes |
| ABAC 基于属性的访问控制 |
根据用户、资源、环境属性动态计算决策 | 极细粒度（属性级） | 高 | 中（策略引擎需分布式部署） | 云 IAM、金融风控 |
| ReBAC 基于关系的访问控制 |
通过实体间关系图推导权限 | 关系粒度 | 高 | 好（图存储可水平扩展） | 社交网络、Google Zanzibar |
选型建议：不要一开始就追求 ABAC 或 ReBAC。80% 的分布式系统用 RBAC + 资源级 Scope 就能覆盖需求。过度设计会导致策略引擎成为新的性能瓶颈。
1.4 分布式鉴权核心架构
下图展示了分布式鉴权的通用架构模式，包含身份提供者、策略决策点、策略执行点三个核心组件：
架构要点：PEP（策略执行点）通常部署在 API Gateway 或服务网格 Sidecar 中，负责拦截请求并调用 PDP 做决策。PDP（策略决策点）是无状态的，可以水平扩展。PAP（策略管理点）负责存储和分发策略，通常使用 etcd、Consul 或数据库。
1.5 分布式鉴权的关键设计原则
- 无状态优先：尽量使用 JWT 等自包含 Token，减少集中式 Session 存储的依赖，降低单点故障风险。
- 最小权限：每个服务只拥有完成其功能所需的最小权限集合，避免过度授权导致横向移动攻击。
- 防御纵深：在 API Gateway、服务网格、应用层分别设置鉴权检查点，不依赖单一安全防线。
- 可审计：所有鉴权决策必须记录日志，包含决策时间、请求方、资源、决策结果，便于事后追溯。
- 策略与代码分离：权限策略不应硬编码在业务代码中，应通过策略引擎动态加载，支持热更新。