第1章：什么是 IDaaS — 定义、演进与企业身份即服务的核心价值 | IDaaS Book
1.1 定义
IDaaS（Identity as a Service，身份即服务）是将身份管理能力以云服务形式交付的一种架构模式。它涵盖了用户身份的创建、维护、认证、授权和审计的全生命周期管理，通过标准化的 API 和协议向应用系统提供统一的身份服务。
Gartner 将 IDaaS 定义为：“通过云端交付的、综合性的身份和访问管理服务，包括身份治理与管理（IGA）、访问管理（AM）和特权访问管理（PAM）等功能。”
从技术角度看，IDaaS 解决的是这样一个核心问题：在一个应用数量爆炸、部署环境异构的世界里，如何让正确的人，在正确的时间，以正确的方式，访问正确的资源？
1.2 为什么需要 IDaaS
1.2.1 传统 IAM 的困境
在 IDaaS 出现之前，企业通常采用本地部署的 IAM 系统。这些系统存在以下痛点：
- 部署周期长：从采购硬件、安装软件到配置集成，动辄数月。
- 维护成本高：需要专业的 IAM 工程师持续运维，升级频繁且风险高。
- 扩展困难：当业务快速增长或需要接入新应用时，传统 IAM 的扩展能力捉襟见肘。
- 集成复杂：每个应用都有自己的用户系统和认证方式，形成了大量的身份孤岛。
- 安全风险集中：自建的 IAM 系统一旦被攻破，所有接入应用都将面临风险。
1.2.2 数字化转型的推动
以下趋势催生了 IDaaS 的快速发展：
- SaaS 应用爆发：企业平均使用超过 100 个 SaaS 应用，每个应用都需要独立的身份管理。
- 多云和混合云：应用分布在多个云平台和数据中心，需要统一的身份层。
- 远程办公常态化：员工从任何地点、任何设备访问企业资源，安全边界消失。
- 零信任安全架构：从"信任但验证"转向"永不信任，始终验证"。
- 合规要求加严：GDPR、个人信息保护法等对身份数据的管理提出了更高要求。
1.2.3 IDaaS 的核心价值
| 价值维度 | 传统 IAM | IDaaS |
|---|---|---|
| 部署时间 | 3-12 个月 | 数天到数周 |
| 运维成本 | 高（需专职团队） | 低（服务商承担） |
| 可扩展性 | 受限于硬件 | 弹性伸缩 |
| 协议支持 | 有限，更新慢 | 持续更新，紧跟标准 |
| 集成生态 | 需定制开发 | 预置数千连接器 |
| 安全更新 | 手动打补丁 | 自动更新 |
| 高可用 | 自建灾备 | 多区域 SLA 保障 |
1.3 IDaaS 的演进历程
第一阶段：目录服务时代（1990s-2000s）
以 Microsoft Active Directory 和 LDAP 目录服务为代表。这个阶段的身份管理主要是"企业内部的员工账号管理"，认证协议以 Kerberos、NTLM 为主，目录访问以 LDAP 为主。身份管理的范畴局限于企业内网，外部用户和合作伙伴的身份管理极其有限。
第二阶段：Web SSO 时代（2000s-2010s）
随着 Web 应用的普及，企业需要支持越来越多的 B/S 架构应用。SAML 2.0 协议的标准化使得跨域 SSO 成为可能。CA Siteminder、Oracle Access Manager 等商业产品主导了这一阶段，CAS 作为开源方案在高等教育（高校）领域广泛使用。
第三阶段：云身份时代（2010s-2020s）
OAuth 2.0 和 OpenID Connect 的标准化开启了现代身份协议时代。Okta 是 IDaaS 品类的开创者，将身份管理全面云化。Microsoft Entra ID（原 Azure AD）凭借 Microsoft 365 生态快速崛起。开源领域 Keycloak 成为事实标准。身份管理的范围从员工扩展到合作伙伴、客户、IoT 设备。
第四阶段：智能身份时代（2020s-至今）
AI/ML 正在深刻改变身份管理：自适应认证根据用户行为动态调整认证强度；身份分析检测异常访问模式；以 Passkey 为代表的无密码认证已在主流平台（Apple、Google、Microsoft）规模化落地；去中心化身份（DID）和可验证凭证（VC）带来全新范式。
1.4 IDaaS 的核心能力
一个完整的 IDaaS 平台通常包含以下核心能力：
- 认证服务：支持多种认证方式（密码、MFA、无密码、社交登录），实现 SSO。
- 授权服务：基于 RBAC、ABAC、PBAC 等模型的细粒度访问控制。
- 用户管理：用户生命周期管理、自助服务、用户画像。
- 身份联邦：通过标准协议与外部身份提供方建立信任关系。
- 目录服务：统一的身份数据存储和同步，支持 LDAP、AD 集成。
- API 安全：API 网关级别的认证和授权，支持 OAuth 2.0 客户端凭证流。
- 审计与合规：全链路身份操作日志，满足合规审计要求。
- 分析和智能：基于 AI 的风险评估、异常检测、身份分析。
1.5 IDaaS 的部署模式
公有云 IDaaS（SaaS）
服务商完全托管，通过多租户架构提供服务。适合大多数企业，尤其是中小企业。典型案例：Okta、Auth0、腾讯云 IDaaS。
私有化部署
将 IDaaS 软件部署在企业自己的数据中心或私有云上。适合对数据主权有严格要求的企业。典型案例：Keycloak 自建、Janssen。
混合部署
认证网关部署在本地，身份管理在云端。兼顾数据主权和云服务的便利性。典型案例：Azure AD + AD FS。
边缘身份
身份服务部署在网络边缘，减少延迟，提高可用性。适用于 IoT 和分布式场景。
1.6 选型考量
选择合适的 IDaaS 方案时，应重点考量：
- 协议标准：是否完整支持 OAuth 2.0 / OIDC / SAML / SCIM？
- 集成生态：预置连接器是否覆盖你使用的应用？
- 可定制性：是否能通过 API、SDK、插件进行定制？
- 安全认证：是否通过 ISO 27001、SOC2、等保等合规认证？
- 数据主权：用户身份数据存储在哪里？是否符合法规要求？
- SLA 保障：承诺的可用性是多少？是否有赔偿机制？
- 成本模型：按用户数计费、按活跃度计费还是买断？
- 锁定风险：迁移成本有多高？是否支持标准格式导出？
- 社区和文档：开源方案的话，社区活跃度和文档质量如何？
- 性能表现：认证延迟、并发处理能力是否满足业务需求？
1.7 小结
IDaaS 不是简单的"云上的 AD"，而是一种全新的身份管理范式。它将身份从"每个应用内部的实现细节"提升为"企业架构的基础设施层"，让应用开发者可以专注于业务逻辑，而不是重复实现认证和授权。
在接下来的章节中，我们将从 IAM 的核心原理出发，深入到每一种标准协议，再到具体的开源实现和部署实践，构建一张完整的 IDaaS 知识地图。
1.8 常见问题：IAM 与 IDaaS
Q1：IAM 和 IDaaS 到底有什么区别？
这是中文身份领域搜索量最高的问题之一。简单说：
IAM（Identity and Access Management，身份与访问管理） 是一套能力范畴：管理谁可以访问什么。它包含认证、授权、用户管理、审计四个核心能力域，是一个抽象概念，可以用任何形式实现。
IDaaS（Identity as a Service，身份即服务） 是一种交付模式：把 IAM 能力以云服务形式提供。就像「计算」和「云计算」的关系——计算是能力，云计算是交付方式。
| 维度 | 传统本地 IAM | IDaaS |
|---|---|---|
| 交付方式 | 软件安装在自己服务器上 | 云服务（SaaS）或私有化部署后暴露 API |
| 运维责任 | 自己运维、升级、打补丁 | 供应商负责（SaaS）或简化运维（自建） |
| 集成方式 | 定制开发、AD/LDAP 对接 | 标准协议（OIDC/SAML）+ 预置连接器 |
| 扩展性 | 受限于硬件采购周期 | 弹性伸缩 |
| 典型产品 | 传统 AD、SiteMinder、Oracle IAM | Okta、Auth0、Keycloak、Entra ID |
记忆方法：问「IAM 还是 IDaaS」就像问「数据库还是 RDS」——IAM 是能力，IDaaS 是产品形态。实际选型时，你选的是「用什么产品来实现 IAM」，而不是在 IAM 和 IDaaS 之间二选一。完整对比——包括选型决策树、混合部署方案和迁移考量，见 IAM 和 IDaaS 区别。
Q2：企业已经部署了 Active Directory / LDAP，还需要 IDaaS 吗？
需要。AD/LDAP 解决的是「内网员工账号管理」，但现代企业面临的问题远超 AD 的范畴：
- SaaS 应用不支持 LDAP：Salesforce、Slack、GitHub 等 SaaS 应用通过 OIDC/SAML 对接，AD 原生不支持这些协议
- 移动端和远程办公：用户不在内网时无法访问 AD，需要反向代理或 VPN，安全性大打折扣
- 合作伙伴和客户身份：AD 主要管员工，外部用户（B2B、CIAM 场景）需要独立身份体系。员工 IAM 和客户 IAM 的需求差异很大，详见 CIAM vs Workforce IAM 全面对比。
- 多因素认证：AD 的 MFA 依赖额外基础设施（AD FS + Azure MFA），IDaaS 原生集成 WebAuthn/TOTP/SMS
正确的做法不是「替代 AD」，而是把 AD 作为 IDaaS 的上游身份源：用户仍然在 AD 中管理，IDaaS 通过 LDAP/LDAPS 同步用户并向上游应用暴露 OIDC/SAML 端点。Keycloak 的 User Federation 就是这个模式的典型实现。详见 Keycloak LDAP / AD 用户联邦。
Q3：中小企业需要 IAM 还是直接上 IDaaS？
分三种情况：
- 10 人以下、3 个以内 SaaS 应用：用 Google Workspace / Microsoft 365 自带身份就够了，不需要单独 IAM
- 10-50 人、5-15 个应用：推荐云 IDaaS（Okta 免费 tier、Auth0 免费额度、腾讯云 IDaaS 试用），开箱即用，无需运维
- 50 人以上或需要私有化部署：考虑 Keycloak 自建或其他开源方案，需要有人维护
中小企业最大的错误是「先用本地账号凑合，等团队大了再上 IAM」——这会让后续迁移成本翻倍。即使预算有限，也至少用 Google/Microsoft 身份做 SSO 登录，避免在应用层自建用户表。更多选型对比见 IDaaS 方案全景对比。
Q4：IAM 一定要上云吗？本地 IAM 过时了吗？
没有过时。本地 IAM 在以下场景仍然是正确选择：
- 金融、政务、军工等强合规行业：数据必须留在本地，不允许出境
- 已有大量本地应用且迁移成本过高：先保留本地 IAM，逐步在边缘接入 IDaaS 做联邦
- 高度定制化的认证流程：自建 Keycloak 可以深度定制（SPI 扩展），SaaS IDaaS 定制能力有限
关键是协议现代化：即使身份数据留在本地，也应该让应用通过 OIDC/SAML 等标准协议接入，而不是继续用 Kerberos/NTLM 或私有 Token。本地 IAM + 标准协议 = 现代本地 IAM，这在很多行业仍是主流。
Q5：IAM 未来会被 IDaaS 完全取代吗？
不会完全取代，但边界会越来越模糊：
- 「IAM」作为产品品类正在消失：Gartner 已将 IAM 魔力象限拆分为 Access Management（AM）和 Identity Governance and Administration（IGA），没有单独的「IAM 产品」
- IDaaS 成为 IAM 的默认交付形态：新项目选型时，即使是私有化部署的 Keycloak，也可以视为一种「自建 IDaaS」
- 专属化部署（Dedicated SaaS）兴起：Auth0、Okta 提供专属实例，SaaS 的运维便利 + 私有化的数据隔离——进一步模糊了 SaaS 和自建的边界
结论：IAM 的概念不会消失，但「买一个软件装到服务器上」的本地 IAM 时代正在收尾，取而代之的是各种形态（公有云、私有云、边缘）的 IDaaS 部署。