另一方面，如果您的应用程序和 SAML Id 提供商之间存在显式信任，则您可以获得有关用户的完整信息（包括姓名和电子邮件），并且由于存在信任关系，因此该信息是可信的。这意味着您倾向于相信 ID 提供商以某种方式验证了所有信息，并且您可以在应用程序级别信任它。如果用户使用未知提供商颁发的 SAML 令牌，您的应用程序将拒绝身份验证。
They are two different protocols of authentication and they differ at the technical level.
From a distance, differences start when users initiate the authentication. With OpenID, a user login is usually an HTTP address of the resource which is responsible for the authentication. On the other hand, SAML is based on an explicit trust between your site and the identity provider so it's rather uncommon to accept credentials from an unknown site.
OpenID identities are easy to get around the net. As a developer you could then just accept users coming from very different OpenID providers. On the other hand, a SAML provider usually has to be coded in advance and you federate your application with only selected identity providers. It is possible to narrow the list of accepted OpenID identity providers but I think this would be against the general OpenID concept.
With OpenID you accept identities coming from arbitrary servers. Someone claims to be http://someopenid.provider.com/john.smith. How you are going to match this with a user in your database? Somehow, for example by storing this information with a new account and recognizing this when user visits your site again. Note that any other information about the user (including his name or email) cannot be trusted!
On the other hand, if there's an explicit trust between your application and the SAML Id Provider, you can get full information about the user including the name and email and this information can be trusted, just because of the trust relation. It means that you tend to believe that the Id Provider somehow validated all the information and you can trust it at the application level. If users come with SAML tokens issued by an unknown provider, your application just refuses the authentication.
OpenID Connect vs SAML
(section added 07-2017, expanded 08-2018)
This answer dates 2011 and at that time OpenID stood for OpenID 2.0. Later on, somewhere at 2012, OAuth2.0 has been published and in 2014, OpenID Connect (a more detailed timeline here).
To anyone reading this nowadays - OpenID Connect is not the same OpenID the original answer refers to, rather it's a set of extensions to OAuth2.0.
While this answer can shed some light from the conceptual viewpoint, a very concise version for someone coming with OAuth2.0 background is that OpenID Connect is in fact OAuth2.0 but it adds a standard way of querying the user info, after the access token is available.
Referring to the original question - what is the main difference between OpenID Connect (OAuth2.0) and SAML is how the trust relation is built between the application and the identity provider:
SAML builds the trust relation on a digital signature, SAML tokens issued by the identity provider are signed XMLs, the application validates the signature itself and the certificate it presents. The user information is included in a SAML token, among other information.
OAuth2 builds the trust relation on a direct HTTPs call from the application to the identity. The request contains the access token (obtained by the application during the protocol flow) and the response contains the information about the user.
OpenID Connect further expands this to make it possible to obtain the identity without this extra step involving the call from the application to the identity provider. The idea is based on the fact that OpenID Connect providers in fact issue two tokens, the access_token, the very same one OAuth2.0 issues and the new one, the id_token which is a JWT token, signed by the identity provider. The application can use the id_token to establish a local session, based on claims included in the JWT token but the id_tokencannot be used to further query other services, such calls to third party services should still use the access_token. You can think of the OpenID Connect then as a hybrid between the SAML2 (signed token) and OAuth2 (access token), as OpenID Connect just involves both.
Microsoft Azure AD 在 2018 年 5 月提交的 8B+ 身份验证请求中，92% 来自支持 OpenID Connect 的应用程序。
OpenID and SAML2 are both based on the same concept of federated identity. Following are some of the difference between them..
SAML2 supports single sign-out - but OpenID does not
SAML2 service providers are coupled with the SAML2 Identity Providers, but OpenID relying parties are not coupled with OpenID Providers. OpenID has a discovery protocol which dynamically discovers the corresponding OpenID Provider, once an OpenID is given. SAML has a discovery protocol based on Identity Provider Discovery Service
Protocol.
With SAML2, the user is coupled to the SAML2 IdP - your SAML2 identifier is only valid for the SAML2 IdP who issued it. But with OpenID, you own your identifier and you can map it to any OpenID Provider you wish.
SAML2 has different bindings while the only binding OpenID has is HTTP
SAML2 can be either Service Provider (SP) initiated or Identity Provider (IdP) initiated. But OpenID always SP initiated.
SAML 2 is based on XML while OpenID is not based on XML.
Most of the application developed in last 3 years were only supporting OpenID Connect.
92% of the 8B+ authentication requests Microsoft Azure AD handed in May 2018 were from OpenID Connect enabled applications.
Putting the technical details aside, being quite late for the party, what I understand that the biggest difference between SAML and other auth standards (inc. OpenID) is that
SAML requires the Identity Provider (IDP) and the Service Provider (SP), to know each other before hand, pre-configured, static authentication and authorization. OpenId (+Connect) doesn't have such a requirement.
This is important for IDPs that want full control over who's accessing the data. Part of the standard is to configure what is provided to specific SPs.
For example, a bank might not want its users to access any services except some predefined ones (because of regulations or other strict security rules).
This doesn't mean that an OpenId IDP, cannot enforce such a restriction. An OpenID implementer can control access, but that's not the purpose of OpenID.
Other than the predefined, strict, static, access control difference, conceptually (not technically), OpenID Connect and SAML are similar.
Bottom line, if you're an SP, you should support what your customers require:
If your customer is an individual end user customers (using their google id for example), forget about SAML. Use OpenID Connect.
If your customer is a bank that wants its employees to use your service and export only static list of data it will provide to your service, the bank will probably want you to support SAML. The bank might have an OpenID implementation with client restriction, which will be your lucky day :)
Both SAML and OpenID can act as identity provider (abbreviated IdP) i.e. decentralized authentication protocol(single sign-on identity).
The Security Assertion Markup Language (SAML) is a set of profiles for exchanging authentication and authorization data across security domains. In the SAML domain model, an identity provider is a special type of authentication authority. Specifically, a SAML identity provider is a system entity that issues authentication assertions in conjunction with an SSO profile of SAML. A relying party that consumes these authentication assertions is called a SAML service provider. Source
OpenIDConnect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID Foundation. OAuth is for authorization protocol, rather than an authentication protocol and OpenID specifically designed as an authentication protocol. OIDC uses simple JSON Web Tokens (JWT), they are easier to consume by JavaScript.
SAML 2.0
OAusth2
OpenID Connect
What is it?
Open standard for authorization and authentication
发布评论
评论（4）
原始 OpenID 2.0 与 SAML
它们是两种不同的身份验证协议，并且在技术层面有所不同。
从远处看，当用户发起身份验证时，差异就开始了。使用 OpenID，用户登录通常是负责身份验证的资源的 HTTP 地址。另一方面，SAML 基于您的站点和身份提供商之间的显式信任，因此接受来自未知站点的凭据的情况相当罕见。
OpenID 身份很容易在网络上获取。作为开发人员，您可以只接受来自不同 OpenID 提供商的用户。另一方面，SAML 提供程序通常必须提前编码，并且您仅将应用程序与选定的身份提供程序联合。可以缩小接受的 OpenID 身份提供商的列表范围，但我认为这违背了一般的 OpenID 概念。
使用 OpenID，您可以接受来自任意服务器的身份。有人声称自己是
http://someopenid.provider.com/john.smith。您将如何将其与数据库中的用户进行匹配？例如，通过使用新帐户存储此信息并在用户再次访问您的网站时识别此信息。请注意，有关用户的任何其他信息（包括他的姓名或电子邮件）均不可信任！另一方面，如果您的应用程序和 SAML Id 提供商之间存在显式信任，则您可以获得有关用户的完整信息（包括姓名和电子邮件），并且由于存在信任关系，因此该信息是可信的。这意味着您倾向于相信 ID 提供商以某种方式验证了所有信息，并且您可以在应用程序级别信任它。如果用户使用未知提供商颁发的 SAML 令牌，您的应用程序将拒绝身份验证。
OpenID Connect 与 SAML
（2017 年 7 月添加部分，2018 年 8 月扩展）
此答案日期为 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 只涉及两者。Original OpenID 2.0 vs SAML
They are two different protocols of authentication and they differ at the technical level.
From a distance, differences start when users initiate the authentication. With OpenID, a user login is usually an HTTP address of the resource which is responsible for the authentication. On the other hand, SAML is based on an explicit trust between your site and the identity provider so it's rather uncommon to accept credentials from an unknown site.
OpenID identities are easy to get around the net. As a developer you could then just accept users coming from very different OpenID providers. On the other hand, a SAML provider usually has to be coded in advance and you federate your application with only selected identity providers. It is possible to narrow the list of accepted OpenID identity providers but I think this would be against the general OpenID concept.
With OpenID you accept identities coming from arbitrary servers. Someone claims to be
http://someopenid.provider.com/john.smith. How you are going to match this with a user in your database? Somehow, for example by storing this information with a new account and recognizing this when user visits your site again. Note that any other information about the user (including his name or email) cannot be trusted!On the other hand, if there's an explicit trust between your application and the SAML Id Provider, you can get full information about the user including the name and email and this information can be trusted, just because of the trust relation. It means that you tend to believe that the Id Provider somehow validated all the information and you can trust it at the application level. If users come with SAML tokens issued by an unknown provider, your application just refuses the authentication.
OpenID Connect vs SAML
(section added 07-2017, expanded 08-2018)
This answer dates 2011 and at that time OpenID stood for OpenID 2.0. Later on, somewhere at 2012, OAuth2.0 has been published and in 2014, OpenID Connect (a more detailed timeline here).
To anyone reading this nowadays - OpenID Connect is not the same OpenID the original answer refers to, rather it's a set of extensions to OAuth2.0.
While this answer can shed some light from the conceptual viewpoint, a very concise version for someone coming with OAuth2.0 background is that OpenID Connect is in fact OAuth2.0 but it adds a standard way of querying the user info, after the access token is available.
Referring to the original question - what is the main difference between OpenID Connect (OAuth2.0) and SAML is how the trust relation is built between the application and the identity provider:
SAML builds the trust relation on a digital signature, SAML tokens issued by the identity provider are signed XMLs, the application validates the signature itself and the certificate it presents. The user information is included in a SAML token, among other information.
OAuth2 builds the trust relation on a direct HTTPs call from the application to the identity. The request contains the access token (obtained by the application during the protocol flow) and the response contains the information about the user.
OpenID Connect further expands this to make it possible to obtain the identity without this extra step involving the call from the application to the identity provider. The idea is based on the fact that OpenID Connect providers in fact issue two tokens, the
access_token, the very same one OAuth2.0 issues and the new one, theid_tokenwhich is a JWT token, signed by the identity provider. The application can use theid_tokento establish a local session, based on claims included in the JWT token but theid_tokencannot be used to further query other services, such calls to third party services should still use theaccess_token. You can think of the OpenID Connect then as a hybrid between the SAML2 (signed token) and OAuth2 (access token), as OpenID Connect just involves both.OpenID 和 SAML2 都基于相同的联合身份概念。以下是它们之间的一些区别。
协议。
OpenID and SAML2 are both based on the same concept of federated identity. Following are some of the difference between them..
Protocol.
抛开技术细节不谈，我认为 SAML 和其他身份验证标准（包括 OpenID）之间的最大区别是
SAML 需要身份提供商 (IDP) 和服务提供商（SP），事先了解对方，预配置，静态身份验证和授权。 OpenId（+Connect）没有这样的要求。
这对于想要完全控制数据访问者的国内流离失所者来说非常重要。标准的一部分是配置向特定 SP 提供的内容。
例如，银行可能不希望其用户访问除某些预定义服务之外的任何服务（由于法规或其他严格的安全规则）。
这并不意味着 OpenId IDP 无法强制执行此类限制。 OpenID 实现者可以控制访问，但这不是 OpenID 的目的。
除了预定义的、严格的、静态的访问控制差异之外，从概念上（非技术上）来看，OpenID Connect和 SAML 类似。
最重要的是，如果您是 SP，您应该支持客户的需求：
Putting the technical details aside, being quite late for the party, what I understand that the biggest difference between SAML and other auth standards (inc. OpenID) is that
SAML requires the Identity Provider (IDP) and the Service Provider (SP), to know each other before hand, pre-configured, static authentication and authorization. OpenId (+Connect) doesn't have such a requirement.
This is important for IDPs that want full control over who's accessing the data. Part of the standard is to configure what is provided to specific SPs.
For example, a bank might not want its users to access any services except some predefined ones (because of regulations or other strict security rules).
This doesn't mean that an OpenId IDP, cannot enforce such a restriction. An OpenID implementer can control access, but that's not the purpose of OpenID.
Other than the predefined, strict, static, access control difference, conceptually (not technically), OpenID Connect and SAML are similar.
Bottom line, if you're an SP, you should support what your customers require:
SAML 和 OpenID 都可以充当身份提供者（简称 IdP），即去中心化身份验证协议（单点登录身份）。
S安全A断言标记L语言 (SAML) 是一组用于跨安全域交换身份验证和授权数据的配置文件。在 SAML 域模型中，身份提供者是一种特殊类型的身份验证机构。具体来说，SAML 身份提供者是一个与 SAML 的 SSO 配置文件结合发出身份验证断言的系统实体。使用这些身份验证断言的依赖方称为 SAML 服务提供商。 来源
OpenID Connect (OIDC) 是 OAuth 2.0（一种授权框架）之上的身份验证层。该标准由 OpenID 基金会控制。 OAuth是用于授权协议，而不是认证协议，而OpenID是专门设计作为认证协议的。 OIDC 使用简单的 JSON Web 令牌 (JWT)，它们更容易被 JavaScript 使用。
来源
Both SAML and OpenID can act as identity provider (abbreviated IdP) i.e. decentralized authentication protocol(single sign-on identity).
The Security Assertion Markup Language (SAML) is a set of profiles for exchanging authentication and authorization data across security domains. In the SAML domain model, an identity provider is a special type of authentication authority. Specifically, a SAML identity provider is a system entity that issues authentication assertions in conjunction with an SSO profile of SAML. A relying party that consumes these authentication assertions is called a SAML service provider. Source
OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID Foundation. OAuth is for authorization protocol, rather than an authentication protocol and OpenID specifically designed as an authentication protocol. OIDC uses simple JSON Web Tokens (JWT), they are easier to consume by JavaScript.
Source