2. 认证与授权基础：Authentication 与 Authorization 的区别、RBAC 模型、ABAC 模型简介
在构建 SSO 与令牌颁发系统之前，必须厘清两个最基础且最容易被混淆的概念：认证（Authentication）与授权（Authorization）。它们是安全架构的左右手，职责截然不同。本章将深入剖析二者的区别，并介绍两种主流的访问控制模型——RBAC 与 ABAC，为后续令牌设计与策略引擎打下理论基础。
2.1 认证 vs 授权：核心职责分离
认证回答的是“你是谁？”，授权回答的是“你能做什么？”。在架构层面，这两个过程必须严格分离，通常由不同的模块或服务处理。
| 维度 | 认证（Authentication） | 授权（Authorization） |
|---|---|---|
| 核心问题 | 你是谁？ | 你能做什么？ |
| 验证对象 | 身份凭证（密码、生物特征、令牌） | 权限策略、角色、属性 |
| 典型机制 | 登录、MFA、OAuth2 授权码流程 | ACL、RBAC、ABAC、策略引擎 |
| 失败结果 | 拒绝访问（401 Unauthorized） | 禁止操作（403 Forbidden） |
| 架构位置 | 网关、认证服务 | 资源服务、策略决策点（PDP） |
| 令牌中的体现 | sub、iss、exp、aud | roles、permissions、scopes |
架构避坑：很多系统将认证与授权逻辑混在同一个中间件中，导致权限变更需要重新登录。正确的做法是：认证产生身份令牌，授权基于令牌中的属性独立决策。SSO 只负责认证，授权由下游资源服务或独立的策略引擎完成。
2.2 RBAC 模型：基于角色的访问控制
RBAC（Role-Based Access Control）是当前企业级应用中最广泛使用的授权模型。其核心思想是：权限不直接赋予用户，而是赋予角色，用户通过扮演角色获得权限。这种间接层极大地简化了权限管理。
2.2.1 RBAC 核心要素
- 用户（User）：系统使用者，唯一标识。
- 角色（Role）：权限的集合，代表一种职责或岗位，如“管理员”、“审计员”、“普通用户”。
- 权限（Permission）：对特定资源的操作许可，通常表示为
resource:action，如document:read、order:delete。 - 会话（Session）：用户激活的角色集合，一个用户可以在一次会话中激活一个或多个角色。
2.2.2 RBAC 标准层级
| 层级 | 名称 | 核心特征 | 适用场景 |
|---|---|---|---|
| RBAC₀ | 核心 RBAC | 用户-角色-权限 三元关系 | 小型系统、CMS |
| RBAC₁ | 角色分层 | 角色继承（上级角色自动拥有下级权限） | 企业组织架构 |
| RBAC₂ | 约束 RBAC | 职责分离（SoD）、互斥角色、基数约束 | 金融、合规系统 |
| RBAC₃ | 统一 RBAC | 角色分层 + 约束 | 大型企业、政府系统 |
架构实践：在 SSO 令牌中，通常不直接携带权限列表，而是携带角色列表。资源服务收到令牌后，根据角色在本地或策略引擎中解析出具体权限。这样做的好处是：权限变更无需重新颁发令牌，只需更新角色-权限映射。
2.3 ABAC 模型：基于属性的访问控制
ABAC（Attribute-Based Access Control）是一种更灵活、更细粒度的授权模型。它不再依赖固定的角色，而是根据主体（用户）、资源、环境的多维属性动态计算访问决策。ABAC 特别适合微服务、多云、IoT 等复杂场景。
2.3.1 ABAC 核心属性维度
- 主体属性（Subject Attributes）：用户 ID、部门、职级、安全等级、地理位置。
- 资源属性（Resource Attributes）：资源类型、所属项目、敏感度标签、创建者。
- 环境属性（Environment Attributes）：访问时间、IP 段、设备类型、网络环境。
- 操作属性（Action Attributes）：操作类型（读/写/删除）、批量操作标识。
2.3.2 ABAC 策略示例
// 策略：仅允许财务部门的员工在工作时间访问敏感财务报表
{
"effect": "Allow",
"condition": {
"subject.department": "Finance",
"resource.sensitivity": "High",
"resource.type": "FinancialReport",
"environment.time": {"between": ["09:00", "18:00"]},
"environment.workday": true
}
}2.3.3 RBAC vs ABAC 对比
| 维度 | RBAC | ABAC |
|---|---|---|
| 粒度 | 粗粒度（角色级） | 细粒度（属性级） |
| 灵活性 | 低，角色变更需管理员操作 | 高，策略可动态组合 |
| 管理复杂度 | 低，适合稳定组织架构 | 高，需要策略引擎与属性源 |
| 性能 | 高，缓存友好 | 中等，策略评估有计算开销 |
| 适用场景 | 企业后台、CMS、传统应用 | 微服务、数据湖、多云、合规审计 |
| 令牌内容 | roles: ["admin", "editor"] | attributes: {dept: "Finance", level: 5} |
架构决策提示：不要盲目追求 ABAC。对于 80% 的企业应用，RBAC 已经足够。ABAC 的策略引擎（如 OPA、Casbin、AWS Cedar）会引入额外的延迟和运维成本。推荐采用混合模型：主体使用 RBAC 粗粒度控制，在关键资源上叠加 ABAC 细粒度约束。
2.4 本章小结
- 认证与授权必须分离：认证产生身份令牌，授权基于令牌属性做决策，二者通过令牌中的 claims 解耦。
- RBAC 是工业标准：通过角色间接管理权限，适合组织架构稳定的场景。支持角色分层与职责分离约束。
- ABAC 提供极致灵活：基于主体、资源、环境的多维属性动态决策，适合复杂、多变的访问控制需求。
- 令牌设计影响授权架构：令牌中携带 roles 还是 attributes，直接决定了资源服务的授权实现方式。