OpenID和SAML有什么区别？

OpenID和SAML有什么区别？

原始OpenID 2.0与SAML

它们是两种不同的身份验证协议，在技术水平上也有所不同。

从远处看，差异在用户启动身份验证时开始。使用OpenID，用户登录通常是负责身份验证的资源的HTTP地址。另一方面，SAML基于站点与身份提供者之间的显式信任，因此很少接受来自未知站点的凭据。

OpenID身份很容易在网上出现。作为开发人员，您可以只接受来自完全不同的OpenID提供程序的用户。另一方面，通常必须预先对SAML提供程序进行编码，并且您仅将选定的身份提供程序与应用程序联合。可以缩小接受的OpenID身份提供者的列表，但是我认为这与一般的OpenID概念背道而驰。

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

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

OpenID Connect与SAML

（增加了07-2017部分，扩展了08-2018）

该答案的日期为2011年，当时OpenID代表OpenID 2.0。后来，在2012年某个地方发布了OAuth2.0，并在2014年发布了OpenID Connect（此处有更详细的时间表）。

对于如今阅读此书的任何人-OpenID Connect与原始答案所指的OpenID都不相同，而是OAuth2.0的一组扩展。

虽然这个答案可以从概念角度来看一些启发，一个非常简洁的版本与OAuth2.0的背景有人来是ID连接是事实上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_tokenid_token access_token。您可以将OpenID Connect视为SAML2（签名令牌）和OAuth2（访问令牌）之间的混合体，因为OpenID Connect仅涉及两者。

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不是。
7. 最近3年开发的大多数应用程序仅支持OpenID Connect。
8. 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，则应支持客户的要求：

1. 如果您的客户是个人最终用户客户（例如，使用其Google ID），请不用担心SAML。使用OpenID Connect。
2. 如果您的客户是一家银行，希望其员工使用您的服务并仅导出将提供给您的服务的静态数据列表，那么该银行可能会希望您支持SAML。银行可能具有受客户限制的OpenID实现，这将是您的幸运日:)

SAML和OpenID都可以充当身份提供者（缩写为IdP），即分散式身份验证协议（单点登录身份）。

该小号 ecurity 甲 ssertion 中号 arkup 大号 anguage（SAML）是一组用于在安全域交换认证和授权数据型材。在SAML域模型中，身份提供者是一种特殊的身份验证授权。具体来说，SAML身份提供者是与SAML的SSO配置文件一起发出身份验证断言的系统实体。消耗这些身份验证断言的依赖方称为SAML服务提供程序。资源

ø笔ID Ç ONNECT（OIDC）是上的OAuth 2.0，授权框架之上的认证层。该标准由OpenID Foundation控制。OAuth用于授权协议，而不是用于专门设计为身份验证协议的身份验证协议和OpenID。OIDC使用简单的JSON Web令牌（JWT），它们更容易被JavaScript使用。

用例场景：

如果您的用户可能只想使用Facebook或Twitter登录，请使用OAuth。如果您的用户因为自己“不想让其他人拥有自己的身份”而运行自己的OpenID提供程序的胡须，请使用OpenID。

资源