一、核心概念与单独解析
1. LDAP（Lightweight Directory Access Protocol，轻量级目录访问协议）
LDAP 不是认证协议，而是一种“目录服务协议”，主要用于存储、查询和管理用户身份数据（如用户名、密码、部门、邮箱等），是SSO体系中常见的“统一身份源”（类似“用户数据库”的角色）。
核心特性：
- 数据结构：采用“树形目录结构”（如
dc=company,dc=com→ou=users→uid=zhangsan），适合存储层级化的身份信息，查询效率高。 - 功能定位：
- 作为“身份数据库”：集中存储企业内所有用户的账号密码，避免各系统单独维护用户数据；
- 支持基础认证：用户登录时，系统可通过LDAP协议校验用户名/密码是否匹配（如校验
uid=zhangsan的userPassword属性）。
- 典型场景：企业内部系统的统一身份源（如对接OA、CRM、文件服务器的用户认证），常与SAML/OAuth配合实现SSO（提供用户数据支撑）。
局限性：
- 仅解决“用户数据存储与基础认证”，无法直接实现跨系统的SSO（需搭配SAML/OAuth等协议）；
- 不支持复杂的权限委托（如第三方应用授权）。
2. SAML（Security Assertion Markup Language，安全断言标记语言）
SAML 是一种基于XML的跨系统认证协议，专门用于实现“企业级SSO”，核心是通过“身份提供商（IdP）”向“服务提供商（SP）”传递“用户已认证”的断言（Assertion），让用户无需在SP端重复登录。
核心角色：
- IdP（Identity Provider，身份提供商）：统一的认证入口（如企业的登录系统），负责校验用户身份并生成“认证断言”；
- SP（Service Provider，服务提供商）：用户需要访问的应用（如企业的CRM、ERP系统），通过接收IdP的断言信任用户身份。
工作流程（SSO场景）：
- 用户访问SP（如CRM系统），SP检测到用户未登录，重定向到IdP的登录页面；
- 用户在IdP输入账号密码（IdP可通过LDAP校验密码）；
- IdP校验通过后，生成包含“用户身份信息”的SAML断言（XML格式），重定向回SP；
- SP验证SAML断言的有效性（如校验签名、有效期），确认后让用户登录SP。
典型场景：
- 企业内部多系统SSO（如IdP对接LDAP，SP对接OA、CRM）；
- 跨企业的信任登录（如企业用户通过自身IdP登录合作伙伴的系统）。
优势与局限：
- 优势：成熟稳定，专为SSO设计，支持细粒度身份信息传递（如用户角色、部门）；
- 局限：基于XML，协议较重；仅支持“认证”（证明用户是谁），不支持“授权”（控制用户能访问第三方应用的哪些资源）。
3. OAuth（Open Authorization，开放授权协议）
OAuth 是一种“授权协议”，核心解决“第三方应用如何在不获取用户密码的情况下，获得用户在某平台的资源访问权限”，常见的2.0版本（OAuth 2.0）也可间接实现SSO。
核心角色：
- 资源所有者（Resource Owner）：用户（如微信用户）；
- 客户端（Client）：第三方应用（如使用微信登录的小游戏）；
- 授权服务器（Authorization Server）：平台的授权系统（如微信的授权服务器），负责发放“授权令牌（Token）”；
- 资源服务器（Resource Server）：存储用户资源的系统（如微信的用户信息服务器），通过Token校验权限。
工作流程（以“微信登录”为例）：
- 用户在第三方应用（如小游戏）选择“微信登录”，应用重定向到微信授权服务器；
- 用户确认授权（允许应用获取自己的昵称、头像）；
- 微信授权服务器发放“授权码”给第三方应用；
- 第三方应用用“授权码”向微信授权服务器换取“访问令牌（Access Token）”；
- 第三方应用用“Access Token”向微信资源服务器请求用户信息；
- 资源服务器校验Token有效后，返回用户信息，第三方应用完成用户登录（实现SSO）。
与SSO的关系：
OAuth 2.0本身是“授权协议”，但通过“获取用户信息并关联本地账号”可实现SSO（如用户用微信登录多个第三方应用，无需重复注册登录）。
典型场景：
- 互联网应用的第三方登录（如微信、QQ、GitHub登录）；
- 微服务架构中的服务间授权（如API网关通过Token校验权限）。
优势与局限：
- 优势：轻量级（基于JSON），支持多种授权模式（如授权码模式、密码模式），适合开放平台场景；
- 局限：原生不强制加密（需配合HTTPS）；仅解决“授权”，若需严格认证需搭配OpenID Connect（OIDC，基于OAuth 2.0的认证层）。
4. SSO（Single Sign-On，单点登录）
SSO 不是具体技术，而是一种认证架构目标：用户在多个关联系统中，只需一次登录，即可访问所有系统（无需重复输入账号密码）。
实现SSO的核心是“信任机制”——多个系统需信任同一个“身份源”（如IdP），由IdP统一管理认证状态，各系统通过协议（SAML/OAuth）获取认证结果。
二、四者的关系与配合实现SSO
LDAP、SAML、OAuth 并非“互斥关系”，而是常配合使用以实现完整的SSO体系，典型架构如下：
架构示例（企业级SSO）：
- 身份源：LDAP 存储企业所有用户的账号、密码、角色信息；
- 认证入口（IdP）：基于SAML搭建IdP系统，IdP通过LDAP校验用户密码；
- 内部应用（SP）：企业的OA、CRM系统作为SAML的SP，通过接收IdP的SAML断言实现SSO；
- 外部应用：若需对接外部系统（如合作伙伴的平台），可通过OAuth 2.0（或OIDC）提供授权登录，授权服务器仍通过LDAP校验用户身份。
三、关键对比与选型建议
| 维度 | LDAP | SAML | OAuth 2.0 |
|---|---|---|---|
| 核心定位 | 身份数据存储/基础认证 | 跨系统认证协议（SSO专用） | 开放授权协议（可间接实现SSO） |
| 数据格式 | LDAP协议格式（二进制/文本） | XML | JSON |
| 适用场景 | 企业内部统一身份源 | 企业级SSO（内部/跨企业） | 第三方登录、API授权 |
| 安全性 | 依赖传输加密（如LDAPS） | 内置签名/加密，安全性高 | 需依赖HTTPS，原生无加密 |
| 与SSO的关系 | 支撑SSO的“身份库” | 实现SSO的“认证协议” | 实现SSO的“授权工具”（需扩展） |
| 典型产品/案例 | OpenLDAP、Active Directory | Okta、Azure AD（IdP） | 微信登录、GitHub OAuth、Keycloak |
选型建议：
- 若需统一存储用户数据：用LDAP（如企业内部用OpenLDAP，Windows环境用Active Directory）；
- 若需企业内部SSO：用SAML（搭配LDAP作为身份源，如IdP用Keycloak，SP用OA系统）；
- 若需第三方登录/开放平台：用OAuth 2.0（或OIDC，如互联网应用对接微信登录）；
- 复杂场景：三者结合（如LDAP存身份 → SAML做内部SSO → OAuth做外部授权）。
四、常见疑问解答
-
LDAP能单独实现SSO吗？
不能。LDAP仅提供用户数据存储和基础认证，无法跨系统传递认证状态，必须搭配SAML/OAuth等协议才能实现SSO。 -
SAML和OAuth的核心区别是什么？
- SAML是“认证协议”：直接传递“用户已认证”的断言，专注SSO；
- OAuth是“授权协议”：传递“访问资源的权限令牌”，不直接证明用户身份（需OIDC补充认证层）。
-
OIDC是什么？与OAuth的关系？
OIDC（OpenID Connect）是基于OAuth 2.0的“认证层”，在OAuth基础上增加了“身份令牌（ID Token）”，可直接证明用户身份，更适合实现SSO（如企业用OIDC替代SAML，实现轻量级SSO）。
注意：本文归作者所有，未经作者允许，不得转载
