原始 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（更详细的时间表在这里）。

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

虽然这个答案可以从概念上阐明一些观点，但对于具有
OAuth2.0 背景的人来说，一个非常简洁的版本是 OpenID Connect 实际上 是
OAuth2.0，但它在访问令牌之后添加了一种查询用户信息的标准方式可用。

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

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

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

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