身份提供商

本文约需 2 分钟阅读

身份提供商 (Identity Provider, IdP) 是一种集中管理用户认证信息，并向其他服务证明「该用户确为本人」的服务。从企业部署的 Okta 和 Microsoft Entra ID (原 Azure AD)，到面向个人的 Google 账户和 Apple ID，无论规模大小，IdP 都构成了现代认证基础设施的核心。如果没有 IdP，用户就必须为每个服务分别创建和管理账户，从而导致密码疲劳和安全风险的增加。

IdP 与 SP 的关系

IdP 是提供认证的一方，SP (Service Provider，服务提供商) 是接收认证的一方。当用户访问 SP 时，SP 会将认证委托给 IdP，IdP 进行身份验证后将结果 (断言) 返回给 SP。通过这一机制，用户只需登录 IdP 一次即可使用多个 SP，从而实现单点登录 (SSO)。

IdP 与 SP 的认证流程

用户

🧑‍💻

① 访问

Slack、Salesforce 等

② 认证委托

IdP

Okta、Entra ID 等

③ IdP 对用户进行认证 → ④ 将断言 (认证结果) 返回给 SP → ⑤ SP 允许访问

主要的 IdP 服务

IdP	主要对象	特点
Okta	企业	超过 7,000 个应用集成。支持零信任
Microsoft Entra ID	使用 Microsoft 365 的企业	与 AD 集成。条件访问
Google Workspace	中小型至大型企业	与 Google 服务的无缝集成
Auth0 (Okta)	开发者与初创公司	灵活的 API。可定制性高

IdP 在 SAML 与 OIDC 中的作用

IdP 向 SP 传达认证结果主要使用两种协议：SAML和OpenID Connect (OIDC)。SAML 基于 XML，面向企业；OIDC 基于 JSON/JWT，适用于现代的 Web 和移动应用，二者各有侧重。在这两种协议中，IdP 的作用都是「验证用户身份并签发认证结果」，但数据格式和通信方式有所不同。

SAML 中的 IdP

签发 XML 格式的 SAML 断言。通过浏览器重定向发送给 SP。与企业现有系统的兼容性高。

OIDC 中的 IdP

签发JWT格式的 ID 令牌。通过 REST API 发送给 SP。与移动应用和 SPA 的契合度高。

IdP 成为单点故障的风险

将认证集中到 IdP 有助于提升便利性和安全性，但也伴随着单点故障 (SPOF) 的风险：一旦 IdP 本身宕机，所有关联服务都将无法登录。在 2023 年的 Okta 入侵事件中，客户的会话令牌经由支持系统被窃取，波及了众多企业。选择 IdP 时，必须慎重评估其可用性 SLA、事件响应体系以及是否具备备用认证手段。初创公司安全检查清单中也讲解了选择 IdP 的要点。

联合身份与目录服务

联合身份 (Federation) 是一种在不同组织之间相互信任认证信息的机制。例如，让经合作企业 IdP 认证的用户能够访问本公司 SP 的情形即属于此类。目录服务 (Active Directory、LDAP 等) 是存储组织内用户信息的数据库，IdP 会参照该目录进行认证。IAM (Identity and Access Management，身份与访问管理)是一个更宽泛的概念，它不仅包含认证，还包含授权 (访问权限的管理)。

常见的误解

存在一种误解，认为「只要部署 IdP，安全就万无一失」，但 IdP 充其量只是将认证入口集中化。如果 IdP 自身的账户没有受到多因素认证 (MFA)的保护，一旦被攻破，所有服务都将面临危险。在部署 IdP 的同时，必须强制启用 MFA、配置条件访问策略并完善日志监控。请同时参阅OAuth 权限风险的文章，了解集成 IdP 时的注意事项。认证安全相关书籍 (Amazon)也可作为参考。

现场使用案例

「在我们这家拥有 500 名员工的公司，当 SaaS 种类超过 40 种时，我们引入了 Okta 作为 IdP。不再需要分别登录各项服务，员工入职和离职时的账户管理工时减少了八成。由于可以在 IdP 端即时停用离职者的访问权限，企业密码策略的运营也变得轻松了许多。」