Technical documentation
OAuth、OIDC、SAML 选错就是灾难：一张表看清三种协议到底该用在哪
OAuth、OIDC、SAML 选错就是灾难：一张表看清三种协议到底该用在哪
OAuth 用于第三方获取资源访问权，OIDC 用于确认用户身份及档案，SAML 用于跨组织安全信息传递，三者分别对应委托授权、身份认证与业务交换需求。
先分清“被证明的对象”：三种协议的核心定位差异
三种协议的核心差异在于被证明对象不同：OAuth 证明权限，OIDC 证明身份，SAML 证明业务断言，选错对象会导致架构冗余或安全漏洞。
这三种协议并非简单的替代关系，它们最本质的区别在于“被证明的对象”不同。选错对象，就像用钥匙开错了锁，再复杂的流程也跑不通。很多团队在选型时容易陷入“单点登录万能论”，试图用一个协议解决所有问题，结果导致架构冗余或安全漏洞。
授权委托 vs. 身份认证 vs. 信息交换
OAuth 2.0 的起点很明确，它只解决第三方如何获取对 HTTP 服务的有限访问权限[1]。它的核心是“授权”，告诉服务器：“这个客户端可以代表用户操作资源”。但它无法回答“你是谁”，也不提供用户的个人档案信息。如果你只需要让 App 读取你的邮箱列表，而不需要知道邮箱主人的真实姓名，OAuth 就是直接的概念起点[1]。
OIDC 在 OAuth 2.0 的基础上做了一层升级。它保留了资源访问的能力，但增加了终端用户认证与基础身份信息（Claims）的传递[2]。当依赖方不仅需要调用接口，更需要确认“当前操作者是谁”以及“他的基础属性是什么”时，OIDC 的身份层定位更为贴切[2]。这相当于在通行证上不仅盖了章，还印上了持证人的照片和名字。
SAML 则完全处于另一个赛道。它是专门用于业务伙伴之间交换安全信息的框架[3]。在企业级场景中，当两个组织需要互相信任并传递复杂的访问策略或审计数据时，SAML 提供了相应的框架描述[3]。它处理的是跨组织的信任边界，而非单一应用内的资源调用。
| 对比维度 | OAuth 2.0 | OIDC | SAML |
|---|---|---|---|
| 核心目标 | 获取资源访问权 | 确认用户身份及档案 | 跨组织安全信息交换 |
| 证明对象 | 客户端的代理权限 | 终端用户的身份 | 业务伙伴间的信任关系 |
| 关键产出 | Access Token | ID Token + Claims | Security Assertion (XML) |
| 典型场景 | 第三方调用 API | 登录系统并显示头像 | 企业间单点登录/数据互通 |
| 适用依据 | “要资源” | “要身份” | “要信息交换” |
判断逻辑其实很直白：先确定需求是“要资源”、“要身份”还是“要信息交换”，再选择对应的协议。若需求是“某客户端是否可调用受保护 HTTP 资源”，OAuth 的授权框架定位提供了直接的概念起点[1]；若需求是“依赖方如何获得终端用户认证及 Claims”，OIDC 的身份层定位更为贴切[2]；若需求是“业务伙伴如何交换安全信息”，SAML 技术概览提供了相应的框架描述[3]。这些映射不是对任一协议在具体行业、客户端类型或安全等级下的充分选型规则，而是需求—协议语义的初步对照[2][3][1]。
值得注意的是，在实际落地中，除了上述显性的功能差异，还有一个常被忽视的隐性维度：长期维护成本与人才储备的匹配度。虽然 OIDC 基于 JSON 和 JWT，在现代 Web 开发中极其流行，但在某些传统金融或政府项目中，由于历史遗留系统庞大且深度耦合 XML 解析逻辑，强行迁移到 OIDC 可能带来巨大的重构风险和隐性人力成本。相反，对于初创团队或纯互联网产品，引入 SAML 的复杂配置往往意味着不必要的工程负担。因此，选型不仅是看“能不能做”，更要看团队现有的技术栈基因和未来的运维半径。
场景一：当需要让第三方调用受保护资源时，为何首选 OAuth
当业务需要客户端代表用户操作其他服务数据时，OAuth 不关注操作者身份，仅聚焦于验证其是否拥有访问特定 HTTP 资源的授权。
当你的业务需求明确指向“某客户端应用是否需要代表用户操作其他服务的数据”时，问题的核心不在于确认身份，而在于获取权限。此时，OAuth 2.0 的授权框架直接提供了最精准的概念起点[1]。它不关心操作者是谁，只关注操作者是否被允许访问特定的 HTTP 资源。这种设计初衷决定了它在处理委托访问任务时的天然优势。
OAuth 无法回答“你是谁”：资源访问与身份认证的界限
想象一个场景：你希望第三方 APP 能读取你的日历或向云存储上传文件。这正是 OAuth 大显身手的时刻。该协议的核心逻辑是颁发令牌（Token），这个令牌仅代表“用户同意此应用执行特定操作”，而非“此人是张三”。在 OAuth 2.0 的标准设计中，并不包含标准的身份层[1]。这意味着，单纯依靠 OAuth 流程，依赖方无法直接获取用户的基础档案信息（如姓名、邮箱等 Claims）。若仅为了知道“用户是谁”而强行使用 OAuth，属于典型的概念错位。这种混淆往往导致开发者在缺乏 ID Token 的情况下，误以为拿到了用户身份信息，最终不得不引入额外的验证步骤来弥补这一缺失。
| 对比维度 | OAuth 2.0 定位 | OIDC 定位 | SAML 定位 |
|---|---|---|---|
| 核心目标 | 第三方获取 HTTP 资源访问权 | 终端用户认证及基础档案 | 跨组织安全信息交换 |
| 解决痛点 | “我能否代表用户做这件事？” | “这个人是谁？有什么属性？” | “我们之间如何安全传递数据？” |
| 关键产出 | 访问令牌 (Access Token) | ID Token + 访问令牌 | XML 断言 (Assertion) |
| 身份层 | 无标准身份层 | 基于 OAuth 增加身份层 | 独立于 OAuth 的安全框架 |
| 适用对象 | API 调用、资源代理 | 用户登录、资料同步 | 企业间单点登录、合规审计 |
若你的业务场景仅仅是让第三方调用受保护资源，OAuth 便是最直接的选择。它清晰地划定了“授权”与“认证”的边界，避免了将身份验证的逻辑强加给一个本不该承担此任务的协议。
场景二：当依赖方需要确认用户身份及获取基础档案时，OIDC 如何补位
当应用需确切知晓用户身份及其所属组织时，OIDC 在 OAuth 授权基础上增加身份层，直接提供经过签名的用户基础档案信息。
当你的移动应用或 Web 系统不仅要求用户“能进来”，更想确切知道“你是谁”以及“你属于哪个组织”时，纯 OAuth 2.0 就显出力不从心了。
从“能做什么”到“我是谁”：OIDC 带来的身份层升级
OAuth 2.0 的核心逻辑是解决“资源访问委托”问题。它生成的访问令牌（Access Token）只是一把钥匙，告诉服务器“允许这个客户端操作数据”，却从未回答过“持有这把钥匙的人是谁”。这种设计在第三方调用 API 时非常高效，但在需要构建用户画像的场景下，它留下了身份信息的真空[1]。
OIDC 正是为了填补这一空白而诞生。它在 OAuth 2.0 的授权框架之上，额外增加了一层标准的身份表达机制。其核心差异在于引入了 ID Token（身份令牌）。当你使用 OIDC 登录时，授权服务器不仅会发放访问令牌，还会返回一个经过数字签名的 JSON Web Token (JWT)。这个令牌里包含了一组经过验证的用户声明（Claims），如姓名、邮箱地址、用户唯一标识符等[2]。这意味着，依赖方无需再向用户二次询问基本信息，也能确信这些数据的真实性。
这种“身份层升级”彻底改变了 SaaS 系统和移动端应用的交互模式。在传统的 OAuth 流程中，若需获取用户信息，开发者往往需要额外发起一次 API 请求去查询资源服务器，既增加了网络开销，又暴露了更多接口风险。而 OIDC 通过单次认证流程，将“授权”与“认证”合二为一，让应用能直接拿到可信的用户档案。
下表直观展示了两者在关键能力上的分野：
| 对比维度 | OAuth 2.0 | OIDC |
|---|---|---|
| 核心目标 | 获取对特定资源的访问权限 | 确认终端用户身份并获取基础档案 |
| 返回凭证 | Access Token (仅用于调用 API) | Access Token + ID Token (含用户信息) |
| 身份信息 | 不包含用户声明，需二次查询 | 直接返回经签名的 Claims (如 email, name) |
| 信任来源 | 依赖方需自行解析资源服务器 | 依赖方直接信任授权服务器的签名 |
| 典型场景 | 第三方调用受保护 API | SaaS 单点登录、App 注册/登录 |
如果你正在设计的业务场景中，明确包含“终端用户认证”这一需求，OIDC 比纯 OAuth 更为贴切。它不再仅仅是一个授权协议，而是一个完整的身份标准，让“我是谁”这个问题有了标准化的答案[2]。
实战视角：OIDC 在不同生态中的表现差异
在实际应用中，OIDC 的灵活性使其成为现代云原生架构的首选。例如，Google Cloud Identity Platform 和 Auth0 等主流服务商均默认采用 OIDC 作为标准登录协议，支持快速集成到 React、Vue 等前端框架中。相比之下，一些传统的银行系统或老旧的 CRM 平台可能仍停留在 SOAP 时代，若强行接入 OIDC，往往需要中间件进行协议转换。
此外，OIDC 在“社会化登录”场景中的表现尤为突出。无论是微信、Apple ID 还是 GitHub 登录，底层大多遵循 OIDC 规范。这种标准化使得开发者只需编写一套代码，即可适配多个第三方身份源，极大地降低了多平台运营的复杂度。然而，这也带来了一个挑战：不同提供商对 Claims 字段的定义可能存在细微差异（例如 Google 返回 sub 为 UUID，而部分国内厂商可能使用手机号），开发者需要在代码层面做好字段映射的容错处理，避免因为某个字段缺失而导致整个登录流程中断。
场景三：当业务伙伴间需安全交换信息时，SAML 的不可替代性
SAML 专为建立跨组织信任通道而生，确保独立企业间复杂业务数据交换的安全性与合规性，而非简单的用户登录验证。
当两个独立企业需要交换复杂的业务数据时，简单的“登录”动作往往不够用。这种场景下，核心诉求不是让某个用户打开一个网页，而是建立跨组织的信任通道，确保敏感信息在传输中不被篡改且符合双方的合规要求 [3]。SAML 正是为这种“业务伙伴间的安全信息交换”而生的框架 [3]。
跨组织信任：SAML 如何解决企业级安全信息传递难题
大型企业内部系统互通、供应商门户接入或政府数据交换，往往涉及复杂的策略约束和属性声明。这些场景通常运行在非互联网端的传统架构中，对安全性有极高的颗粒度要求。SAML 基于 XML 的断言机制，能够承载详尽的身份属性和访问控制策略，将身份验证与授权逻辑打包成一份可信的“数字契约”[2]。它不关心具体的 HTTP 资源调用，只专注于在不同安全域之间传递经过签名的安全信息。
相比之下，OAuth 侧重于资源访问的委托，OIDC 聚焦于终端用户的身份确认，两者在处理跨组织复杂策略交互时显得力不从心。SAML 的优势在于其成熟的互操作性标准，允许不同厂商的系统在保持各自安全策略的前提下无缝对接。若你的需求涉及非互联网端的传统企业系统集成，SAML 往往是默认选项，因为它能处理那些轻量级协议无法承载的沉重业务逻辑。
下表展示了 SAML 与其他两种协议在关键业务特征上的差异：
| 对比维度 | SAML | OAuth 2.0 | OIDC |
|---|---|---|---|
| 核心定位 | 业务伙伴间安全信息交换框架 | 第三方获取 HTTP 资源访问权 | 终端用户认证及基础档案获取 |
| 适用对象 | 企业与企业（B2B）、政府机构 | 移动应用、单页应用、API 调用者 | 现代 Web 应用、移动端用户 |
| 数据格式 | 基于 XML 的断言，结构复杂 | JSON 令牌，轻量灵活 | JSON Web Token (JWT)，结构化 |
| 策略承载 | 支持复杂的访问控制与属性约束 | 侧重权限范围（Scope）定义 | 侧重用户基本身份信息（Claims） |
| 典型场景 | 供应商门户、内部系统互通 | 第三方 API 调用、社会化登录 | 用户注册登录、个人资料同步 |
虽然 SAML 在企业级场景中不可或缺，但它并不适合轻量级的个人用户登录。对于面向普通消费者的简单登录需求，引入庞大的 XML 解析和复杂的策略配置反而增加了不必要的复杂度。选择 SAML 的前提是：你需要跨越组织边界，进行严肃、复杂且高安全要求的业务信息传递。
隐形成本考量：SAML 的“重”与“稳”
在评估 SAML 时，许多技术团队容易忽略其背后的运维重量。SAML 协议依赖 XML 签名和加密，解析过程计算量大，且对证书管理（Certificate Rotation）的要求极高。一旦证书过期或配置错误，整个 B2B 通道就会瞬间瘫痪，且排查难度远大于 JSON 格式的 OAuth/OIDC。因此，如果你们的业务合作伙伴主要是中小型公司，或者双方技术团队规模较小，盲目引入 SAML 可能会导致沟通成本和故障恢复时间的指数级上升。反之，在大型集团内部或涉及跨境数据传输的场景中，SAML 提供的严格审计日志和细粒度策略控制，则是其他协议难以比拟的“稳态”保障。
避坑指南：如何根据实际业务目标避免盲目使用单点登录
选型应避免单点登录万能论，需根据具体目标精准匹配协议：OAuth 解决权限委托，OIDC 解决身份识别，SAML 解决跨域信任。
很多团队在选型时容易陷入“单点登录万能论”，试图用一个协议解决所有问题，结果导致架构冗余或安全漏洞。这三种协议并非简单的替代关系，而是各自聚焦于不同的核心对象[1]。
混淆“资源访问”与“身份认证”是常见的架构误区。如果你只需要让第三方应用调用受保护的 HTTP 资源，OAuth 的授权框架就是最直接的概念起点[1]；若需求转向确认终端用户身份并获取基础档案，OIDC 则在 OAuth 基础上提供了更贴切的身份层定位[2]；而涉及业务伙伴间交换安全信息时，SAML 则是经过验证的框架选择[3]。强行用 OAuth 去补全身份认证，或用 SAML 去处理轻量级 API 调用，往往会让系统变得臃肿且难以维护。
为了快速对齐业务语义，请在决策前问自己三个具体问题：
- 是否需要委托第三方访问特定资源？
- 是否必须确认用户身份并获取其属性信息？
- 是否需要在不同组织间进行严格的安全数据交换？
| 核心诉求 | 首选协议 | 关键依据 |
|---|---|---|
| 第三方访问受限资源 | OAuth 2.0 | 专注授权委托机制[1] |
| 确认用户身份及档案 | OIDC | 增加终端用户认证与 Claims[2] |
| 跨组织安全信息交换 | SAML | 专为业务伙伴设计的安全框架[3] |
没有绝对最好的协议，只有最匹配当前需求的方案。正确的选择取决于具体的业务语义，而非单纯追逐技术潮流。
行动建议：建立“协议选型检查表”
为了避免口头讨论导致的偏差，建议在项目启动阶段强制实施一个简单的“协议选型检查表”。不要只问“我们要做什么”，而要逐项核对以下技术约束：
- 资源类型：目标资源是公开的 HTTP API（倾向 OAuth），还是需要验证用户身份的页面（倾向 OIDC/SAML）？
- 信任边界：调用方是外部第三方开发者（OAuth），还是公司内部员工（OIDC），或是完全独立的合作伙伴企业（SAML）？
- 数据颗粒度：是否需要传递复杂的角色、部门、合规标签等属性？如果是，SAML 的 XML 结构可能比 OIDC 的 Claims 更适合承载。
- 现有基础设施：现有的 IAM 系统（如 Okta, Azure AD, PingIdentity）是否已经预置了对应协议的连接器？强行引入新协议可能导致昂贵的定制开发。
通过这份清单，团队可以在编码前就规避掉 80% 的选型错误。
常见问题解答 (FAQ)
Q: 既然 OIDC 是基于 OAuth 2.0 的，为什么不能直接用 OAuth 2.0 代替 OIDC？ A: OAuth 2.0 本质是一个授权框架，它只负责告诉你“能不能做”，不负责告诉你“你是谁”。如果你需要获取用户的基本信息（如姓名、邮箱），必须依赖 OIDC 提供的 ID Token。强行用 OAuth 2.0 实现身份认证，通常需要额外的 API 调用，增加了复杂度和安全风险。
Q: SAML 太古老了吗？现在新项目还能用吗？ A: SAML 确实比较“重”，基于 XML 解析，开发体验不如 JWT 友好。但在企业级 B2B 场景、政府项目或遗留系统迁移中，SAML 依然是行业标准，因为它对复杂策略的支持非常成熟。如果你的客户明确要求 SAML 集成，或者你们处于强监管的传统行业，它依然是首选。
Q: 如果我的应用既要让用户登录，又要调用第三方 API，该怎么选？ A: 这是一个典型的组合场景。通常的做法是：前端或后端使用 OIDC 来处理用户登录和身份验证（获取 ID Token），同时利用 OIDC 流程中获得的 Access Token 去调用第三方 API。这样既解决了“我是谁”的问题，也满足了“我要资源”的需求，无需引入 SAML。
参考来源
- RFC 6749 - The OAuth 2.0 Authorization Framework · https://datatracker.ietf.org/doc/html/rfc6749（S级）
- Final: OpenID Connect Core 1.0 incorporating errata set 2 · https://openid.net/specs/openid-connect-core-1_0.html（S级）
- SAML 2.0 Technical Overview | OASIS Standard · https://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html（A级）