3. 授权与访问控制：RBAC模型、ABAC模型、OAuth 2.0与OpenID Connect协议

3.1 基于角色的访问控制（RBAC）

RBAC 核心要素

元素	描述	示例
用户 (User)	系统的操作者	张三、李四
角色 (Role)	权限的集合，代表一种职责	管理员、审计员、普通员工
权限 (Permission)	对特定资源的操作许可	读取工资单、修改订单、删除日志
会话 (Session)	用户激活的角色映射	张三以“审计员”身份登录

RBAC 模型层级（NIST标准）

• RBAC₀ (核心RBAC)： 用户-角色-权限 基本三元组。
• RBAC₁ (层级RBAC)： 支持角色继承（如：高级工程师继承工程师权限）。
• RBAC₂ (约束RBAC)： 引入职责分离（SSD/DSD），如：同一人不能同时担任“采购员”和“审批员”。
• RBAC₃ (统一RBAC)： 同时包含层级与约束。

RBAC 代码示例（伪代码）

// 定义角色与权限
role admin {
    permissions: ["read:all", "write:all", "delete:all"]
}
role auditor {
    permissions: ["read:logs", "read:reports"]
}
role operator {
    permissions: ["read:orders", "write:orders"]
}

// 用户分配角色
user alice {
    roles: ["admin"]
}
user bob {
    roles: ["auditor", "operator"]  // 多角色
}

// 访问控制检查
function checkAccess(user, resource, action):
    for role in user.roles:
        if (role.hasPermission(action + ":" + resource)):
            return GRANT
    return DENY

3.2 基于属性的访问控制（ABAC）

ABAC 属性分类

属性类别	示例	说明
主体属性 (Subject)	用户ID、部门、职级、安全等级	谁在请求？
资源属性 (Resource)	文件类型、数据分类、所属项目	要访问什么？
环境属性 (Environment)	访问时间、IP地址、设备状态	在什么环境下？
操作属性 (Action)	读取、写入、删除、导出	要做什么？

ABAC 策略示例（XACML风格）

Policy "允许财务人员在工作时间访问财务系统"
  Target: 
    Subject.role == "财务"
    Resource.type == "财务系统"
    Action.id == "access"
  Condition:
    Environment.currentTime >= "09:00" 
    AND Environment.currentTime <= "18:00"
    AND Subject.department == Resource.ownerDepartment
  Effect: Permit

3.3 OAuth 2.0 授权框架

OAuth 2.0 角色

• 资源所有者 (Resource Owner)： 用户，拥有数据。
• 客户端 (Client)： 第三方应用，需要访问资源。
• 授权服务器 (Authorization Server)： 验证用户身份并颁发令牌。
• 资源服务器 (Resource Server)： 托管受保护资源，验证令牌。

四种授权模式

授权模式	适用场景	安全性
授权码模式 (Authorization Code)	服务端应用（Web/移动端）	最高（支持PKCE增强）
隐式模式 (Implicit)	纯前端应用（已不推荐）	较低（令牌在URL中）
密码模式 (Resource Owner Password)	高度信任的客户端（如第一方应用）	中等（需暴露密码）
客户端凭证模式 (Client Credentials)	服务间通信（M2M）	高（无用户参与）

OAuth 2.0 令牌使用示例

// 客户端携带令牌访问资源
GET /api/v1/user/profile HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

// 资源服务器验证令牌
function validateToken(accessToken):
    // 1. 验证签名 (使用授权服务器的公钥)
    // 2. 检查过期时间 (exp)
    // 3. 检查作用域 (scope)
    // 4. 返回用户信息或拒绝
    return jwt.verify(accessToken, publicKey)

3.4 OpenID Connect (OIDC) 身份认证协议

OIDC 核心概念

概念	说明	与OAuth 2.0的关系
ID Token	JWT格式，包含用户身份信息（iss, sub, aud, exp, name, email等）	OAuth 2.0 没有此概念
UserInfo Endpoint	受保护的API，返回用户详细信息	使用Access Token访问
Scope: openid	必须包含此scope才能触发OIDC流程	OAuth 2.0 的扩展
Claims	用户属性声明（如姓名、邮箱、头像）	由ID Token或UserInfo返回

OIDC 认证流程（简化）

1. 客户端发起认证请求 (包含scope=openid profile email)
2. 授权服务器验证用户身份 (登录页面)
3. 用户同意授权
4. 授权服务器返回授权码 (Authorization Code)
5. 客户端用授权码换取令牌 (Token Endpoint)
6. 令牌响应包含:
   - access_token (用于调用API)
   - id_token (JWT, 用于身份认证)
   - refresh_token (可选)
7. 客户端验证ID Token (签名、iss、aud、exp)
8. 客户端从ID Token中提取用户信息 (sub, name, email等)
9. 可选: 使用access_token调用UserInfo Endpoint获取更多信息

OIDC 与 OAuth 2.0 对比

维度	OAuth 2.0	OpenID Connect
主要目的	授权 (Access)	认证 (Authentication) + 授权
核心令牌	Access Token (不透明或JWT)	ID Token (JWT) + Access Token
用户身份	不关心用户是谁	明确标识用户 (sub claim)
标准范围	scope: read, write	scope: openid, profile, email
典型场景	API授权、服务间通信	单点登录 (SSO)、用户登录

OIDC 集成最佳实践

• 始终使用授权码模式 + PKCE： 防止授权码拦截攻击，即使是移动端或单页应用。
• 验证ID Token： 必须验证签名、issuer、audience、expiration和nonce。
• 使用HTTPS： 所有令牌传输必须通过TLS加密。
• 最小权限原则： 只请求必要的scope和claims。
• 令牌存储： 避免在localStorage存储敏感令牌，优先使用HttpOnly Cookie或后端会话。