第3章：IAM 认证与授权深度辨析 — AuthN vs AuthZ 的核心区别与设计原则 | IDaaS Book
3.1 一个经典的误解
“我已经登录了，为什么还不能访问这个页面？”
这是 IAM 工程师最常听到的问题之一。在企业 IAM（身份与访问管理）体系中，用户将"能够登录"等同于"能访问所有功能"，这恰恰混淆了认证和授权的本质区别。理解这一区别是 IAM 系统设计的第一课——如果你不知道 AuthN 和 AuthZ 的分界线在哪里，你的 IAM 架构从一开始就埋下了安全债务。关于 IAM 整体框架，推荐先阅读 IAM 基础概念。
让我们用机场的比喻来理解：
- 认证：出示身份证件，证明"我是张三"
- 授权：出示登机牌，证明"我被允许乘坐CA1234航班"
- 有身份证（已认证）但没有登机牌（未授权），你上不了飞机
- 有登机牌（已授权）但没有身份证（未认证），你同样上不了飞机
3.2 认证（Authentication，AuthN）
3.2.1 认证的核心问题
认证回答三个递进的问题：
- 这个用户存在吗？（身份识别）
- 这个用户是他声称的那个人吗？（身份验证）
- 当前是否已经验证过？（会话管理）
3.2.2 认证方式分类
基于知识的认证
用户知道什么。
- 静态密码：最传统的方式，问题在于用户喜欢弱密码、复用密码、写密码在便签上。
- 安全问题：你第一个宠物的名字？这类问题的答案往往比密码更容易被猜中或通过社交工程获取。
- 图片密码：选择正确的图片组合，在移动端有一定应用场景。
基于持有的认证
用户拥有什么。
- 短信/邮箱验证码：最普及，但短信验证码存在 SS7 协议攻击与 SIM 劫持（SIM-swap）风险，NIST SP 800-63B 与 OWASP 均已不再将其作为强认证因素，新项目建议优先 TOTP、推送或 Passkey。
- 硬件 Token：U-Key、YubiKey。物理设备，安全性高，但有丢失风险和分发的物流成本。
- 软件 Token：TOTP（Google Authenticator、Authy）或推送通知认证。
- 智能卡：带有芯片的卡片，常见于大型企业和政府机构。
基于固有的认证
用户是什么。
- 指纹识别：方便，但指纹可以被复制，且皮肤状态影响识别率。
- 面部识别：Apple Face ID 是标杆实现，普通摄像头的安全性存疑。
- 虹膜识别：精度极高但设备昂贵。
- 声纹识别：可远程使用，但录音回放和 AI 合成构成威胁。
- 行为生物识别：击键模式、鼠标轨迹、持手机的角度。无感知认证，正在快速发展。
3.2.3 认证的技术实现
基于 Session 的认证
1. 用户提交用户名和密码
2. 服务端验证通过，创建 Session，返回 Session ID（Cookie）
3. 后续请求携带 Cookie，服务端查找 Session 验证特点：有状态，服务端存储 Session；可即时吊销；扩展困难（Session 同步）。
基于 Token 的认证
1. 用户提交用户名和密码
2. 服务端验证通过，签发 Token（JWT）
3. 客户端存储 Token，后续请求在 Authorization 头中携带
4. 服务端验证 Token 签名和有效期特点：无状态，服务端不需要存储；水平扩展友好；吊销需要额外机制（黑名单、短有效期）。
基于证书的认证
使用 X.509 客户端证书进行 TLS 双向认证（mTLS）。常见于服务间通信和高安全场景。
FIDO2 / WebAuthn
无密码认证的开放标准，使用公私钥对进行认证。私钥存储在用户设备的可信区域（TPM/Secure Enclave），永远不会离开设备，服务端只存储公钥，天然抗钓鱼。Passkey（通行密钥） 是 FIDO2/WebAuthn 面向消费者的落地形态，由 Apple、Google、Microsoft 自 2022 年起在各自平台原生支持，私钥可在用户设备间端到端加密同步，已成为无密码认证的主流实践。
3.2.4 认证安全的关键概念
防暴力破解：限制错误尝试次数，临时或永久锁定账户。
防重放攻击：使用 Nonce、时间戳、Token 有效期。
防钓鱼：FIDO2/WebAuthn 的凭据与 Relying Party ID（rpId，依赖方域名 eTLD+1）绑定，并校验 origin，使认证断言（assertion）只能在对应域名使用，钓鱼站点无法重放（WebAuthn 不签发 Token，产物是带签名的 assertion）。
凭证存储：密码必须单向哈希（bcrypt、scrypt、Argon2），绝不能明文或可逆加密存储。
3.3 授权（Authorization，AuthZ）
3.3.1 授权的核心问题
授权不是二元的是/否，而是多维度的问题：
- 这个用户能否对这个资源执行这个操作？
- 这个用户在这个时间、从这个地点、用这个设备访问，是否允许？
- 如果是"部分允许"（如可以看到列表但不能修改），如何表达？
3.3.2 授权策略的表达
ACL（访问控制列表）
一对一的关系。直接列出"谁可以对什么做什么"。
Resource: /reports/sales-2024.xlsx
- Alice: read, write
- Bob: read
- Carol: (none - implicit deny)优点：直观。缺点：管理成本随用户和资源的增加而爆炸。
RBAC（基于角色的访问控制）
通过角色简化权限分配。
Alice → [角色: 销售经理] → [权限: 查看销售报告, 编辑销售数据]
Bob → [角色: 销售代表] → [权限: 查看自己的销售数据]这是目前最广泛使用的授权模型。实现简单，管理方便。缺点是角色爆炸——当业务的精细度超过角色设计时，需要不断创建新角色。
ABAC（基于属性的访问控制）
精细化、动态化的授权。
Rule: 允许访问 IF
user.department = "sales" AND
user.clearance_level >= resource.sensitivity AND
time.current BETWEEN "09:00" AND "18:00" AND
device.trust_score > 0.8优点：灵活，支持复杂策略。缺点：策略难以可视化和管理，性能开销大。
PBAC（基于策略的访问控制）
策略 = 规则 + 条件 + 操作。使用自然语言或 DSL 编写策略，通过 PDP（Policy Decision Point）评估。
ReBAC（基于关系的访问控制）
源自 Google Zanzibar 论文。用关系图表达权限，特别适合社交网络、协作工具等场景。
权限: 编辑文档 IF
主体 is a member of 文档.workspace OR
主体 is an editor of 文档 OR
主体 is a manager of 文档.owner3.4 认证与授权的关系
认证是授权的前提，但不等同于授权
认证（AuthN） 授权（AuthZ）
│ │
├─ 确认身份 ├─ 确认权限
├─ 登录时发生 ├─ 每次访问时发生
├─ 凭据验证 ├─ 策略评估
├─ 产出：身份声明 ├─ 产出：访问决策
│ │
└─────────┬──────────┘
│
安全上下文实际流程
请求 → 认证拦截器 → "这是谁？"
↓
认证成功？
↓ Yes
授权拦截器 → "他能做这个吗？"
↓
允许/拒绝常见反模式
- 将授权信息放在 Token 中且不设有效期：用户角色变了，但旧 Token 仍然可用。
- 仅在网关层做授权，业务层不校验：网关配置错误可能导致越权。
- 将用户 ID 作为授权判断的唯一依据：攻击者可以伪造用户 ID。
- 前端隐藏按钮代替后端权限检查：用户可以绕过前端直接调用 API。
3.5 IAM 实践要点
在企业 IAM 系统中，认证和授权的工程落地远比概念区分复杂：
- AuthN 和 AuthZ 应当解耦。IAM 认证服务负责"他是谁"，IAM 授权服务负责"他能做什么"。这是 IAM 架构设计的基本法则——解耦后你可以独立升级认证方式（如增加 Passkey）而不影响授权策略。
- Token 应当短有效期，使用 Refresh Token 续期。
- 权限变更后，应能在合理时间内生效（建议 < 5 分钟）。在 IAM 会话管理层面，这意味着 Token 吊销机制必须可靠——详见 IAM 会话管理与 Token 生命周期。
- 所有授权决策都应记录日志——这是 IAM 审计合规的基础。
- 默认拒绝（Deny by Default）——什么都不声明，默认就是不能访问。
- 在 API 网关、应用中间件、业务逻辑三层都进行授权检查。
- 授权模型选型直接影响 IAM 系统的可维护性——RBAC 简单但易角色爆炸，ABAC 灵活但策略复杂，ReBAC 适合关系密集型场景。完整的授权模型对比见 IAM RBAC、ABAC、ReBAC 授权模型对比与选型指南。