身份提供商(IdP)基础：SAML 2.0与OIDC/OAuth 2.0协议详解
聊到多云身份治理，第一个绕不开的话题就是身份提供商（IdP）。说白了，IdP就是那个负责“发身份证”和“验票”的中心节点。你在阿里云、AWS、Azure之间来回切换，总得有个统一的“大管家”来证明你是谁。
我最早接触IdP是在2016年，当时帮一家金融客户做混合云迁移。他们内部有十几个应用，每个都自己维护一套密码。嗯，那场面，光是密码重置工单就堆满了IT部门的桌面。后来我们上了统一的IdP，问题才真正解决。
这一章，我们重点拆解两个最主流的协议：SAML 2.0和OIDC/OAuth 2.0。顺便聊聊市面上主流的IdP产品怎么选。
SAML 2.0协议详解
SAML 2.0，全称Security Assertion Markup Language。名字挺长，但核心逻辑很简单：用户向IdP登录，IdP给服务提供商（SP）发一个“断言”，证明用户是谁、有什么权限。
我在项目中遇到过不少团队把SAML和SSO直接划等号。其实SAML只是SSO的一种实现方式，而且它主要面向企业级Web应用。你想想看，Salesforce、Workday、Office 365这些老牌SaaS，几乎都支持SAML 2.0。
SAML 2.0的核心流程（SP-Initiated SSO）：
- 用户访问SP（比如Salesforce）的受保护资源。
- SP发现用户未认证，生成SAML认证请求（AuthnRequest），重定向到IdP。
- 用户在IdP登录（如果已有会话则跳过）。
- IdP生成SAML断言（Assertion），通过HTTP POST或Artifact方式返回给SP。
- SP验证断言签名，解析用户属性，建立本地会话。
这里有个关键点：SAML断言是XML格式的，而且必须签名。我见过有人为了省事，把签名验证关掉——结果被中间人攻击，用户身份被冒用。千万别这么干。
避坑指南：我曾经在项目里遇到SAML断言超时问题。默认的断言有效期通常是5分钟，但有些IdP和SP的时钟偏差超过30秒就会失败。建议把时钟偏差放宽到120秒，同时确保NTP同步。
SAML 2.0的缺点也很明显：协议重、解析慢、移动端支持差。XML解析在浏览器里还好，但在原生App里就非常痛苦。所以后来OIDC才逐渐成为主流。
OIDC/OAuth 2.0协议详解
OAuth 2.0本身不是身份认证协议，它是授权协议。但OIDC（OpenID Connect）在OAuth 2.0之上加了一层身份认证层，变成了真正的“认证+授权”协议。
我个人习惯把OAuth 2.0比作“酒店房卡”——它只告诉门卫你能进哪个房间，但不证明你是谁。而OIDC就是“身份证+房卡”——它既证明你是谁，又告诉你有什么权限。
OAuth 2.0的四种授权模式
| 授权模式 | 适用场景 | 安全级别 |
|---|---|---|
| 授权码模式（Authorization Code） | Web后端应用、有Server端的App | 高 |
| 隐式模式（Implicit） | 纯前端SPA（已不推荐） | 低 |
| 密码模式（Resource Owner Password） | 高度信任的第一方应用 | 中 |
| 客户端凭证模式（Client Credentials） | 服务间通信、M2M场景 | 高 |
你想想看，现在谁还用隐式模式？我上次见到它还是在2019年的一个遗留系统里。现在主流做法是授权码模式 + PKCE，连SPA都这么用。
OIDC的核心概念
OIDC在OAuth 2.0的基础上引入了几个新东西：
- ID ：JWT格式，包含用户身份信息（iss、sub、aud、exp等）。
- UserInfo Endpoint：获取用户详细信息的API。
- Scope：openid是必须的，profile、email、address等是可选。
小技巧：我在做多云身份治理时，习惯把ID 的sub字段作为用户的全局唯一标识。但要注意，不同IdP的sub格式可能不同——比如Azure AD是UUID，Okta是随机字符串。建议在IdP侧配置统一的NameID格式。
OIDC的流程比SAML轻量得多。一个典型的授权码流程只需要两次HTTP请求（一次获取code，一次换取），而SAML至少需要三次重定向。这也是为什么现代云原生应用几乎都选OIDC。
SAML 2.0 vs OIDC/OAuth 2.0
| 对比维度 | SAML 2.0 | OIDC/OAuth 2.0 |
|---|---|---|
| 消息格式 | XML（签名+加密） | JWT（JSON） |
| 传输方式 | HTTP POST / Redirect / Artifact | HTTP POST / Redirect / 直接API调用 |
| 移动端支持 | 差（XML解析慢） | 好（JWT轻量） |
| API友好度 | 低（需解析XML） | 高（原生JSON） |
| 单点登出（SLO） | 支持（但实现复杂） | 支持（通过RP-Initiated Logout） |
| 主流场景 | 企业SaaS、传统Web应用 | 移动App、SPA、微服务、云原生 |
我个人建议：新项目优先选OIDC，除非你对接的是Salesforce、Workday这类老牌SaaS。它们对SAML的支持更成熟，OIDC反而可能遇到兼容性问题。
主流IdP产品对比
市面上主流的IdP产品，我基本都用过。下面这张表是我个人的使用感受：
| 产品 | 协议支持 | 多云集成 | 成本 | 我的评价 |
|---|---|---|---|---|
| Azure AD | SAML 2.0, OIDC, WS-Fed | Azure + AWS + GCP | 随E3/E5订阅 | 微软生态首选，但SCIM配置略复杂 |
| Okta | SAML 2.0, OIDC, SCIM | 7000+预集成应用 | 按用户/月 | 集成最广，但价格偏高 |
| Auth0 | OIDC, OAuth 2.0, SAML | 开发者友好 | 按月活跃用户 | 适合自定义场景，但企业版不便宜 |
| Keycloak | SAML 2.0, OIDC, OAuth 2.0 | 开源，可自托管 | 免费 | 功能强大，但运维成本高 |
| PingIdentity | SAML 2.0, OIDC, WS-Fed | 大型企业 | 按用户/年 | 适合复杂企业策略，但学习曲线陡 |
我的选择建议：
- 如果你已经在用微软全家桶，Azure AD是顺理成章的选择。
- 如果你需要快速集成大量SaaS应用，Okta的预集成库能省很多事。
- 如果你是创业公司或开发者团队，Auth0的开发者体验最好。
- 如果你预算有限且有人力运维，Keycloak是开源界的王者。
嗯，这里要注意：不要只看功能，还要看生态。我见过一个团队选了冷门IdP，结果对接AWS IAM Identity Center时发现不支持SCIM，最后只能手动同步用户——那叫一个痛苦。
知识体系总览
下面这张图，是我对本章核心逻辑的梳理。你可以把它当作一个“导航图”：
这张图把SAML和OIDC的核心子概念、以及主流IdP产品串在了一起。你可以看到，协议选择决定了技术架构，产品选择决定了运维复杂度。两者需要一起考虑。
我的个人习惯：在做多云身份治理方案时，我会先画一张类似的图，把协议、产品、集成方式都标出来。这样团队讨论时，大家一眼就能看到全貌，不会在细节里迷失。
好了，这一章的内容就到这里。SAML和OIDC的细节其实还有很多，比如SAML的Metadata交换、OIDC的Discovery和JWKS端点——这些我们在后面的章节里会逐一展开。你现在只需要记住：SAML重、稳、老；OIDC轻、快、新。选哪个，看你的场景。