身份认证协议简介：OAuth 2.0、OIDC、SAML、LDAP
老实说，很多人在做安全架构时，第一个绕不开的坑就是“选协议”。
OAuth 2.0、OIDC、SAML、LDAP，这四个词听起来像绕口令。
但它们的定位完全不同。用错了，轻则接口调不通，重则留下安全漏洞。
我见过不少团队把OAuth当认证用，结果泄露后一脸懵。
咱们今天就把这几个协议掰开揉碎，讲清楚。
1. 协议的定位：谁该在哪个场景出现？
先来个总览。这四种协议，其实分两大阵营：
- 授权与认证协议：OAuth 2.0、OIDC、SAML。它们解决“你是谁”和“你能干啥”。
- 目录访问协议：LDAP。它解决“用户信息存在哪，怎么查”。
你想想看，一个典型的微服务架构里，很可能四个都用上。
LDAP管组织架构，OAuth 2.0管API授权，OIDC做人机认证，SAML做企业SSO。
不是说越新越好，也不是越复杂越安全。关键是场景对不对。
2. OAuth 2.0：只授权，不认人
不少人觉得OAuth就是登录。这是个误解。
OAuth 2.0 是一个授权框架。它解决的是“A应用能不能访问B应用里的资源”。
举个例子：你点“用微信登录”某个网站。那个网站拿到的是一个Access 。
这个只能访问你允许的那部分数据。比如昵称和头像。它不代表“你是张三”。
| 模式 | 适用场景 | 安全级别 |
|---|---|---|
| 授权码模式 | Web后端应用 | 最高（推荐） |
| 隐式模式 | 纯前端SPA | 较低（已不推荐） |
| 密码模式 | 受信任第一方应用 | 中等 |
| 客户端凭证模式 | 服务间通信 | 中等 |
我的实践心得：
我一直坚持一个原则：能用授权码模式就别用别的。很多安全问题都出在“图省事”。
3. OIDC：OAuth 2.0 的认证层
OIDC 全称 OpenID Connect。它是在 OAuth 2.0 之上加了一层“身份认证”。
说白了，OIDC让你不仅能搞到Access ，还能拿到一个ID 。
ID 是JWT格式。里面包含了用户ID、签发者、有效期。
一个小技巧：
用OIDC做SSO时，记得验证ID 的签名和issuer。很多攻击靠的就是伪造签发方。
4. SAML：企业级的“老大哥”
SAML比OAuth出生早。它是XML格式的。
企业环境里，SAML依然很常见。尤其是做跨域单点登录时。
我记得有一个项目，客户要求必须用SAML 2.0。因为他们的HR系统只支持这个。
SAML的核心流程是：
- 用户访问服务提供者（SP）
- SP重定向到身份提供者（IdP）
- 用户在IdP登录
- IdP生成SAML Assertion，返回给SP
- SP验证Assertion，放行
我曾经踩过的一个坑：
配置SAML时，签名和加密的证书最好分开用。我见过有人一套证书用了五年，泄露了都不知道。
5. LDAP：目录服务的老兵
LDAP不是用来做互联网登录的。它是用来查“组织里的人在哪”。
很多公司用LDAP管理员工信息。比如部门、邮箱、手机号。
它像一个树形结构的电话本。你通过DN（Distinguished Name）找到一个人。
为什么还要提LDAP？
因为很多企业会把LDAP和OAuth结合。LDAP负责存“谁是张三”，OAuth负责给“张三的App授权”。两者不冲突。
6. 协议对比：一张表讲清
| 协议 | 核心目标 | 数据格式 | 主要场景 |
|---|---|---|---|
| OAuth 2.0 | 授权委托 | JSON/Bearer | 第三方API访问 |
| OIDC | 身份认证+授权 | JWT (ID ) | 用户登录、SSO |
| SAML | 单点登录（企业级） | XML Assertion | 跨企业系统认证 |
| LDAP | 目录信息查询 | LDIF / 二进制 | 组织架构管理 |
你可能会问：那我该怎么选？
我的建议很简单：
- 如果你是互联网应用，对外提供API → OAuth 2.0 + OIDC
- 如果你是大企业，要和供应商系统对接 → SAML
- 如果你要管理内部用户信息 → LDAP
一个小提醒：
别把LDAP当成认证协议。它主要做“读”操作。虽然也能做绑定认证，但不适合高并发场景。
7. 实战：当协议需要联动时
最后聊一个实际案例。
我之前参与过一个金融项目。系统里：
- 用LDAP存员工和客户信息
- 用OAuth 2.0 + OIDC做内部系统登录（SSO）
- 用SAML对接监管机构的外部系统
你看，四个协议全用上了。不是冲突，是互补。
关键在于：LDAP提供身份数据源，OIDC负责认证流程，SAML处理跨域断言。
每个协议把自己那部分做好就行。别试图用一个协议包打天下。