OpenID和SAML有什么区别?

What is the difference between OpenID and SAML?

OpenID和SAML有什么区别?


原始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 Connect与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令牌,由身份提供商签名。应用程序可以使用id令牌根据JWT令牌中包含的声明建立本地会话,但id令牌不能用于进一步查询其他服务,此类对第三方服务的调用仍应使用访问令牌。您可以将OpenID Connect视为SAML2(签名令牌)和OAuth2(访问令牌)之间的混合,因为OpenID Connect只涉及两者。


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

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

  • 把技术细节放在一边,为聚会迟到,我明白SAML和其他auth标准(包括OpenID)之间的最大区别在于

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

    这对于希望完全控制谁访问数据的国内流离失所者来说非常重要。标准的一部分是配置提供给特定SP的内容。

    例如,银行可能不希望其用户访问除某些预定义服务之外的任何服务(由于法规或其他严格的安全规则)。

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

    除了预定义的,严格的,静态的,访问控制差异,概念上(不是技术上),OpenID Connect和SAML是相似的。

    最重要的是,如果您是SP,您应该支持客户的要求:

  • 如果您的客户是个人最终用户(例如使用他们的Google ID),请忘记SAML。使用OpenID Connect。
  • 如果您的客户是希望其员工使用您的服务并仅导出其将提供给您的服务的静态数据列表的银行,则银行可能会希望您支持SAML。银行可能有一个客户端限制的OpenID实现,这将是你的幸运日:)

  • SAML和OpenID都可以充当身份提供者(缩写为IdP),即分散式认证协议(单点登录身份)。

    安全断言标记语言(SAML)是一组用于跨安全域交换身份验证和授权数据的配置文件。在SAML域模型中,身份提供者是一种特殊类型的身份验证授权。具体而言,SAML身份提供程序是一个系统实体,它与SAML的SSO配置文件一起发出身份验证断言。使用这些身份验证断言的依赖方称为SAML服务提供程序。资源

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

    用例场景:

    Use OAuth if your users might just want to login with Facebook, or Twitter. Use OpenID if your users are neckbeards that run their own OpenID providers because they"don't want anyone else owning their identity".

    enter image description here
    资源