原始 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，但它添加了一个标准的 { 2}，在访问令牌可用之后。
参考原始问题 - 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 只涉及两者。
OpenID 和 SAML2 都基于相同的联合身份概念。以下是它们之间的一些区别..
SAML2 支持单点注销——但 OpenID 不支持 SAML2 服务提供者与 SAML2 身份提供者耦合，但 OpenID 依赖方不与 OpenID 提供者耦合。 OpenID 有一个发现协议，一旦给出 OpenID，它就会动态地发现相应的 OpenID 提供者。 SAML 有一个基于身份提供者发现服务协议的发现协议。使用 SAML2，用户与 SAML2 IdP 耦合 - 您的 SAML2 标识符仅对发布它的 SAML2 IdP 有效。但是使用 OpenID，您拥有自己的标识符，并且可以将其映射到您希望的任何 OpenID 提供者。 SAML2 有不同的绑定，而 OpenID 唯一的绑定是 HTTP SAML2 可以是服务提供者 (SP) 发起的，也可以是身份提供者 (IdP) 发起的。但是 OpenID 总是 SP 发起的。 SAML 2 基于 XML，而 OpenID 不基于 XML。过去 3 年开发的大多数应用程序仅支持 OpenID Connect。 2018 年 5 月，Microsoft Azure AD 提交的 8B+ 身份验证请求中有 92% 来自启用了 OpenID Connect 的应用程序。
撇开技术细节不谈，迟到了，据我所知，SAML 和其他身份验证标准（包括 OpenID）之间的最大区别在于
SAML 要求身份提供者 (IDP) 和服务提供者 (SP) 事先相互了解、预先配置、静态身份验证和授权。 OpenId (+Connect) 没有这样的要求。
这对于希望完全控制谁在访问数据的 IDP 很重要。该标准的一部分是配置提供给特定 SP 的内容。
例如，银行可能不希望其用户访问除某些预定义服务之外的任何服务（因为法规或其他严格的安全规则）。
这并不意味着 OpenId IDP 不能强制执行这样的限制。 OpenID 实现者可以控制访问，但这不是 OpenID 的目的。
除了预定义的、严格的、静态的访问控制差异之外，在概念上（不是技术上），OpenID Connect 和 SAML 是相似的。
最重要的是，如果您是 SP，您应该支持客户的需求：
如果您的客户是个人最终用户客户（例如使用他们的 google id），请忘记 SAML。使用 OpenID 连接。如果您的客户是一家银行，希望其员工使用您的服务并仅导出它将提供给您的服务的静态数据列表，那么该银行可能希望您支持 SAML。银行可能有一个带有客户限制的 OpenID 实现，这将是你的幸运日 :)
SAML 和 OpenID 都可以充当身份提供者（简称 IdP），即去中心化身份验证协议（单点登录身份）。
Security Assertion Markup Language (SAML) 是一个集合用于跨安全域交换身份验证和授权数据的配置文件。在 SAML 域模型中，身份提供者是一种特殊类型的身份验证机构。具体来说，SAML 身份提供者是一个系统实体，它与 SAML 的 SSO 配置文件一起发布身份验证断言。使用这些身份验证断言的依赖方称为 SAML 服务提供者。 Source
OpenID Connect (OIDC) 是 OAuth 2.0（一个授权框架）之上的一个身份验证层。该标准由 OpenID 基金会控制。 OAuth 是授权协议，而不是认证协议，OpenID 是专门设计为认证协议的。 OIDC 使用简单的 JSON Web 令牌 (JWT)，它们更容易被 JavaScript 使用。
SAML 2.0 OAusth2 OpenID Connect 是什么？授权和认证的开放标准 授权的开放标准 认证的开放标准 历史 2001 年由 OASIS 开发 2006 年由 Twitter 和 Google 部署 2014 年部署 OpenID 基金会 主要用例 企业应用程序的 SSO API 授权 消费者应用程序的 SSO 格式 XML JSON JSON
