【身份与访问控制工程】IAM 全景：为什么这是高价值赛道

2020 年 12 月，SolarWinds 被植入后门，波及 18000 多家机构。2023 年 9 月，MGM 度假村遭勒索软件攻击，损失超过 1 亿美元——攻击者只打了一通电话给服务台，冒充员工重置了 Okta 的 MFA 令牌。2024 年 10 月，Okta 自己承认其支持系统被攻破，攻击者获取了部分客户的 HAR 文件（HTTP Archive），其中包含了明文的 Session Cookie。

这些事件的共同逻辑是什么？攻击者没有破解加密算法，没有绕过防火墙，没有挖掘零日漏洞。他们攻击的是身份系统本身——凭证被盗用、会话被劫持、MFA 被社工绕过。当网络边界消失之后，身份就是新的边界。而这道边界的工程质量，决定了一个组织到底是”被攻破”还是”受损可控”。

这就是 IAM（Identity and Access Management，身份与访问控制）从 IT 支撑系统变成安全架构核心赛道的根本原因。

一、IAM 的四个核心问题

IAM 解决的不是一个技术问题，而是四个层层递进的问题：

1. 你是谁？（认证，Authentication）：用户、设备、服务如何证明自己的身份。从密码到 Passkey，从 Session 到 JWT，从单因素到自适应 MFA。
2. 你能做什么？（授权，Authorization）：已认证的主体能访问哪些资源、执行哪些操作。从 RBAC 到 ABAC 到 ReBAC 到 Zanzibar 式的图关系授权。
3. 你的生命周期是什么？（治理，Governance）：身份从创建、变岗、休假、离职到注销的完整生命周期。从手动开通到 SCIM 自动化，从 PAM 特权管理到审计追溯。
4. 我怎么管理这一切？（基础设施，Infrastructure）：身份系统的部署、运维、监控、迁移和高可用。从自建 Keycloak 到采购 Auth0/Okta/Entra，从单租户到多租户 CIAM 平台。

这四个问题在工程中不是先后出现的，而是同时存在的。一个 B2B SaaS 平台在接过第一个”我们要接 SSO”的客户需求时，它同时踏入了认证协议（OIDC/SAML）、令牌管理（JWT/Refresh Token）、多租户授权和身份治理四件事。

二、现代 IAM 的五层技术栈

如果把 IAM 当成一个工程系统来拆，它的技术栈大致分成五层：

flowchart TD
  subgraph L1["第一层：协议与互操作"]
    OIDC["OIDC / OAuth 2.1"]
    SAML["SAML"]
    SCIM["SCIM"]
    LDAP["LDAP"]
  end

  subgraph L2["第二层：令牌与会话"]
    JWT["JWT / JWS / JWE"]
    Session["Session / Refresh Token"]
    JWKS["JWKS / Token Introspection"]
  end

  subgraph L3["第三层：认证强度"]
    MFA["TOTP / WebAuthn / Passkey"]
    Adaptive["自适应认证 / 风险引擎"]
    Workload["mTLS / SPIFFE / Workload Identity"]
  end

  subgraph L4["第四层：授权与策略"]
    RBAC["RBAC / ABAC / ReBAC"]
    Zanzibar["Zanzibar 图关系授权"]
    PEP["OPA / Cedar / 策略引擎"]
  end

  subgraph L5["第五层：治理与平台"]
    CIAM["CIAM / B2B 多租户"]
    PAM["PAM / IGA"]
    Platform["自建 vs 采购 / Keycloak / Auth0"]
  end

  L1 --> L2 --> L3 --> L4 --> L5

第一层（协议与互操作）是 IAM 的语言层。OIDC 定义了”怎么用第三方账号登录”，OAuth 2.1 定义了”怎么委托访问权限”，SAML 定义了”企业 SSO 怎么在 XML 世界运转”，SCIM 定义了”账号开通和注销怎么自动化”。这层不直接解决安全问题，但没有统一的语言，后面的所有层都无从谈起。

第二层（令牌与会话）是 IAM 的流通层。JWT 解决了”怎么把身份信息安全地编码进令牌”，JWS/JWE 分别解决了”怎么签名”和”怎么加密”，Refresh Token 和 Session 解决了”令牌的生命周期管理”。这层的工程决策（令牌有效期、吊销策略、密钥轮换频率）是安全事故发生后区别”令牌泄露”和”令牌泄露导致全面失陷”的核心变量。

第三层（认证强度）是 IAM 的防守层。TOTP、WebAuthn、Passkey 解决了”怎么证明是你本人而不是拿到你密码的人”，自适应认证解决了”在什么条件下要求额外的认证因素”，Workload Identity 解决了”不是人而是服务的时候怎么认证”。

第四层（授权与策略）是 IAM 的决定层。从 RBAC 的角色树到 ABAC 的属性表达式，从 Google Zanzibar 的图关系授权到 OPA/Cedar 的策略即代码——这层解决的是”知道了你是谁之后，你能不能做这件事”。这层的工程复杂度最高，因为业务规则的表达能力、查询延迟、策略管理成本三者之间存在根本性的权衡。

第五层（治理与平台）是 IAM 的工程化层。CIAM（Customer IAM）和 Workforce IAM 是不同的架构，PAM 和 IGA 是安全合规的硬需求，“自建还是采购”是每个技术负责人必须回答的问题。

三、这个系列能解决什么

目前中文互联网的 IAM 内容呈现两个极端：要么是”OAuth 2.0 四种授权模式”的三页入门（只覆盖了第一层的 20%），要么是 Auth0/Okta 的英文产品文档（解决的是特定产品怎么用，不是系统怎么设计）。中间缺失的是从协议原理到工程落地的那一段——也就是本系列要填补的内容。

具体来说，这个系列会围绕五个问题展开：

1. OIDC 和 OAuth 2.1 到底能解决哪些场景，边界在哪里？ OIDC 是为”谁在用这个浏览器”设计的，不是你所有认证需求的答案。当你需要服务间认证、设备认证、API 授权时，OIDC 的哪些部分能用，哪些不能？详见第 02、03、10 篇。

2. JWT 好用但不是银弹——什么场景不该用 JWT？吊销困境怎么系统性地解？ JWT 把”查 Session”变成了”验签名”，代价是令牌过期之前全是活令牌。Refresh Token 轮换、Token Introspection、基于事件的吊销（如”用户密码被重置”）怎么做？详见第 06、07 篇。

3. RBAC 不够用了——ABAC、ReBAC、Zanzibar 各自解决什么问题，什么时候该上？ 5000 个角色、50 个属性规则和一张关系图之间的本质区别是什么？Zanzibar 的一致性模型（提到 Zanzibar 的人 100% 会说”支持一致性和低延迟”，但没说怎么做到的）的真正约束是什么？详见第 11、12、13 篇。

4. B2B SaaS 的多租户权限系统怎么设计才不在第 10 个客户时爆炸？ 每个租户要自定义角色、要有组织树、要审批流、要数据隔离——这四件事会互相打架。从架构上怎么解？详见第 14、18 篇。

5. 自建还是采购——Keycloak、Auth0、Okta、Entra 的工程边界在哪里？ 自建 Keycloak 省下的授权费用，在运维、定制、高可用、多活上要补回去多少？什么规模下自建比采购更划算？详见第 16、17、20 篇。

四、与已有文章的关系

本站已有若干认证授权主题的先行文章，它们和本系列形成不同的层次：

阅读建议：如果你对认证授权完全没概念，建议先快速翻一遍 wauth/ 下的三篇科普。如果已有基础认知，直接从这个系列开始即可——本系列在涉及基础概念时会简要回顾，但不会从头讲起。

五、推荐阅读路径

• 要接企业客户 SSO：02（OIDC）→ 04（SAML）→ 05（SCIM）→ 06（JWT/JWKS）→ 17（选型）
• 要做 B2B SaaS 权限系统：11（权限模型）→ 12（Zanzibar）→ 13（策略引擎）→ 14（多租户）→ 18（CIAM）
• 要补安全认证体系：03（OAuth 2.1）→ 06（JWT）→ 07（会话/吊销）→ 08（MFA/Passkey）→ 09（自适应认证）
• 要做身份平台选型/治理：16（Keycloak）→ 17（选型对比）→ 19（PAM/IGA）→ 20（迁移与事故）

六、写作约定

• 所有协议描述以对应 RFC 当前版本为准，标注 RFC 编号和 Section。
• 源码引用标注项目、版本、文件路径。
• 安全相关建议标注适用版本和已知边界。
• 不构成任何具体产品的采购建议——选型部分提供的是工程判断框架，不是商业推荐。

下一篇：企业单点登录：OIDC 与现代 SSO