OpenID 和 SAML 有什么区别？

Question

OpenID 和 SAML 有什么区别？

Answer 1

原始 OpenID 2.0 与 SAML

它们是两种不同的身份验证协议，并且在技术层面上有所不同。

从远处看，差异始于用户启动身份验证。对于 OpenID，用户登录通常是负责身份验证的资源的 HTTP 地址。另一方面，SAML 是基于您的站点与身份提供者之间的明确信任，因此接受来自未知站点的凭据是相当罕见的。

OpenID 身份很容易在网络上传播。作为开发人员，您可以只接受来自非常不同的 OpenID 提供商的用户。另一方面，SAML 提供者通常必须预先编码，并且您仅将您的应用程序与选定的身份提供者联合。可以缩小接受的 OpenID 身份提供者的列表，但我认为这违反了一般的 OpenID 概念。

使用 OpenID，您可以接受来自任意服务器的身份。有人自称是http://someopenid.provider.com/john.smith。您将如何将其与数据库中的用户匹配？不知何故，例如通过使用新帐户存储此信息并在用户再次访问您的站点时识别此信息。请注意，有关用户的任何其他信息（包括他的姓名或电子邮件）都不能被信任！

另一方面，如果您的应用程序与 SAML Id 提供者之间存在显式信任，则您可以获得有关用户的完整信息，包括姓名和电子邮件，并且这些信息可以被信任，因为信任关系。这意味着您倾向于相信 Id Provider 以某种方式验证了所有信息，并且您可以在应用程序级别信任它。如果用户使用未知提供商颁发的 SAML 令牌，您的应用程序只会拒绝身份验证。

OpenID 连接与 SAML

（07-2017 年添加的部分，08-2018 年扩展的部分）

这个答案日期为 2011 年，当时 OpenID 代表 OpenID 2.0。后来，在 2012 年的某个地方，OAuth2.0 已经发布，在 2014 年，OpenID Connect（更详细的时间表here）。

对于现在阅读本文的任何人 - OpenID Connect 与原始答案所指的 OpenID 不同，而是 OAuth2.0 的一组扩展。

虽然this answer 可以从概念上阐明一些观点，但对于具有 OAuth2.0 背景的人来说，一个非常简洁的版本是 OpenID Connect 是实际上是 OAuth2.0，但它增加了一个标准访问令牌可用后querying the user info的方式。

参考原始问题 - OpenID Connect (OAuth2.0) 和 SAML 之间的主要区别是如何在应用程序和身份提供者之间建立信任关系：

• SAML 在数字签名上建立信任关系，身份提供者颁发的 SAML 令牌是签名的 XML，应用程序验证签名本身及其提供的证书。用户信息包含在 SAML 令牌中以及其他信息中。

• OAuth2 在应用程序对身份的直接 HTTPs 调用上建立信任关系。请求包含访问令牌（由应用程序在协议流期间获得），响应包含有关用户的信息。

• OpenID Connect 进一步扩展了这一点，使获取身份成为可能无需这个额外的步骤涉及从应用程序到身份提供者的调用。这个想法是基于这样一个事实，即 OpenID Connect 提供者实际上发布了 两个 令牌，access_token，同一个 OAuth2.0 问题和新的，id_token，这是一个 JWT 令牌，由身份提供者签名。应用程序可以使用 id_token 建立本地会话，基于 JWT 令牌中包含的声明，但 id_token 不能用于 进一步查询其他服务，此类对第三方服务的调用应仍然使用access_token。您可以将 OpenID Connect 视为 SAML2（签名令牌）和 OAuth2（访问令牌）的混合体，因为 OpenID Connect 只涉及两者。

Answer 2

OpenID 和 SAML2 都基于相同的联合身份概念。以下是它们之间的一些区别..

1. SAML2 支持单点注销 - 但 OpenID 不支持
2. SAML2 服务提供者与 SAML2 身份提供者耦合，但 OpenID 依赖方不与 OpenID 提供者耦合。 OpenID 有一个发现协议，一旦给出 OpenID，它就会动态地发现相应的 OpenID 提供者。 SAML 有一个基于身份提供者发现服务的发现协议 协议。
3. 使用 SAML2，用户与 SAML2 IdP 耦合 - 您的 SAML2 标识符仅对发布它的 SAML2 IdP 有效。但是使用 OpenID，您拥有自己的标识符，并且可以将其映射到您希望的任何 OpenID 提供者。
4. SAML2 有不同的绑定，而 OpenID 唯一的绑定是 HTTP
5. SAML2 可以是服务提供商 (SP) 发起的，也可以是身份提供商 (IdP) 发起的。但 OpenID 总是由 SP 发起。
6. SAML 2 基于 XML，而 OpenID 不基于 XML。
7. 过去 3 年开发的大多数应用程序仅支持 OpenID Connect。
8. 2018 年 5 月，Microsoft Azure AD 提交的 8B+ 身份验证请求中有 92% 来自支持 OpenID Connect 的应用程序。

Answer 3

抛开技术细节不谈，迟到了，据我所知，SAML 与其他身份验证标准（包括 OpenID）之间的最大区别在于

SAML 要求身份提供者 (IDP) 和服务提供者 (SP) 事先相互了解，预配置，静态 身份验证和授权。 OpenId (+Connect) 没有这样的要求。

这对于希望完全控制谁在访问数据的 IDP 很重要。标准的一部分是配置提供给特定 SP 的内容。

例如，银行可能不希望其用户访问除某些预定义服务之外的任何服务（因为法规或其他严格的安全规则）。

这并不意味着 OpenId IDP 不能强制执行此类限制。 OpenID 实现者可以控制访问，但这不是 OpenID 的目的。

除了预定义的、严格的、静态的访问控制差异之外，在概念上（不是技术上），OpenID Connect 和SAML 是相似的。

归根结底，如果您是 SP，您应该支持客户的需求：

1. 如果您的客户是个人最终用户客户（例如使用他们的 google id），请忘记 SAML。使用 OpenID Connect。
2. 如果您的客户是一家银行，希望其员工使用您的服务并仅导出它将提供给您的服务的静态数据列表，则该银行可能希望您支持 SAML。银行可能有一个带有客户限制的 OpenID 实施，这将是你的幸运日 :)

Answer 4

SAML 和 OpenID 都可以充当身份提供者（简称 IdP），即去中心化身份验证协议（单点登录身份）。

S安全Assertion Markup L语言（SAML）是一组用于跨安全域交换身份验证和授权数据的配置文件。在 SAML 域模型中，身份提供者是一种特殊类型的身份验证机构。具体来说，SAML 身份提供者是一个系统实体，它与 SAML 的 SSO 配置文件一起发布身份验证断言。使用这些身份验证断言的依赖方称为 SAML 服务提供者。 Source

OpenID Connect (OIDC) 是 OAuth 2.0 之上的身份验证层，授权框架。该标准由 OpenID 基金会控制。 OAuth 是授权协议，而不是认证协议，OpenID 是专门设计为认证协议的。 OIDC 使用简单的 JSON Web Tokens (JWT)，它们更容易被 JavaScript 使用。

	SAML 2.0	OAusth2	OpenID Connect
What is it?	Open standard for authorization and authentication	Open standard for authorization	Open standard for authentication
History	Developed by OASIS in 2001	Deployed by Twitter and Google in 2006	Deployed the OpenID Foundation in 2014
Primary use case	SSO for enterprise apps	API authorization	SSO for consumer apps
Format	XML	JSON	JSON

Source