来源：https://jads.blog/identity-management-saml-vs-oauth2-vs-openid-connect-c9a06548b4c5
慕课网：
https://www.imooc.com/learn/557
其他几篇中文
https://www.cnblogs.com/Tony100/p/10452591.html
https://segmentfault.com/a/1190000023938486
https://www.cnblogs.com/Tony100/p/10452591.html
解释清楚
https://zhuanlan.zhihu.com/p/95064385
阮一峰的解释
http://www.ruanyifeng.com/blog/2019/04/oauth_design.html
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
openid的解释
https://zhuanlan.zhihu.com/p/95064385
所有技术的综合
https://juejin.cn/post/6844903634094784520
https://www.ubisecure.com/education/differences-between-saml-oauth-openid-connect/
比较全面：
https://blog.csdn.net/iamlake/article/details/93415206
SAML和OAuth:有什么区别?
OAuth是一个比SAML稍新一些的标准，由谷歌和Twitter从2006年开始联合开发。它的开发部分是为了弥补SAML在移动平台上的不足，并且基于JSON而不是XML。
除了SAML不那么出色的移动支持，两者之间有什么区别?正如我们所看到的，SAML标准定义了提供者如何同时提供身份验证和授权服务。另一方面，OAuth只处理授权。OpenID Connect是一个更新的标准，于2014年开发，提供身份验证服务，并在OAuth之上分层。
另一个主要区别是它们的用例。虽然SAML在理论上是为在开放互联网上使用而设计的，但在实践中，它最常部署在企业网络中用于单点登录。相比之下，OAuth是谷歌和Twitter为互联网规模而设计的。
这一切都始于组织需要一种方法来集中他们的身份验证系统，以更好地管理和安全。这就是单点登录(SSO)的由来。单点登录(SSO)是一种集中的会话和用户身份验证服务，其中一组登录凭证可以用于访问多个应用程序。它的美就在于它的简单;该服务在一个平台上对您进行身份验证，使您能够透明地登录到多个内部服务，而不必每次登录和退出。
接下来，第三方应用程序开发人员想要使用内部api将其集成到他们的产品和解决方案中，这显然是一个挑战。然后社交网络的出现让事情变得更加复杂，我们目前有成千上万的应用支持通过社交网络进行身份验证，如Facebook，谷歌，Twitter, LinkedIn等。这些体系结构中的问题是如何在保持事情尽可能简单的同时提高安全性。解决方案?联邦身份（Federated Identities）。
目前，联邦身份的三种主要协议是:SAML、OAuth2和OpenID Connect。在深入研究这三个协议之前，让我们讨论一下人们容易混淆的一些常见概念。
一、身份验证和授权
当涉及到安全性和访问权限时，身份验证和授权是人们容易忽略的两个术语，而且常常被误认为是同一件事。身份验证是验证你的身份而授权是验证你能访问什么。
身份验证是在用户访问系统之前验证登录凭据。当涉及到安全性时，建议在授予用户访问权限之前至少使用两个身份验证因素。（2FA、MFA、数字和物理令牌等)。
授权发生在身份验证过程之后，在授予您对所需资源(如数据库、文件、存储库等)的访问权之前，先验证您的权限。一个实际的例子是，一旦员工的登录被验证，就是查看他可以访问哪些楼层。
授权和身份验证对于安全性和访问管理都是至关重要的，尽管它们背后有不同的概念，但它们对系统的基础设施都是至关重要的，理解它们对于身份和访问管理是关键。
一、SAML
安全性断言标记语言(Security Assertion Markup Language，SAML)是一种基于xml的开放标准，用于单点登录(SSO)实现。SAML 2.0于2005年发布，是该标准的当前版本。
SAML用于双方之间的身份验证和授权:服务提供商(Office365、Salesforce、G Suite等)和身份提供商(Okta、OneLogin、Ping Identity等)。服务提供者(SP)同意在身份验证过程中信任身份提供者(Identity Provider ，IdP)。这是通过IdP发送的包含用户授权和身份验证的SAML XML文档完成的，然后重定向到服务提供者。
让我们考虑这个例子:
身份提供者(IdP): Okta
服务提供商(SP): Salesforce应用程序
1、用户试图从Chrome登录到他的公司的Salesforce应用程序。
2、Salesforce应用程序通过生成SAML请求来响应
3、Chrome重定向用户到一个SSO URL, Okta解析SAML请求，验证用户(这可能是通过用户名和密码，双因素认证或MFA是用户不在公司的内部网络;如果用户已经在Okta上进行了身份验证，则跳过这一步)并生成一个SAML响应。
4、Okta将编码的SAML响应重新发送给Chrome
5、Chrome将SAML响应重定向到Salesforce应用程序
6、如果验证成功，用户将登录到Salesforce应用程序并被授予对所有各种资源的访问权。
二、OAuth2
“我怎么能让一个应用程序在不提供密码的情况下访问我的数据?”
OAuth2是一个用于授权的开放标准，它允许应用程序为应用程序提供“委托授权”。与其他提供身份验证的框架不同，OAuth只授权设备、API和服务器使用访问令牌，而不是凭据，它通过HTTPS工作。
如果你看过下面的对话，那就是我们要讨论的。这是一个询问是否可以代表您访问数据的应用程序。这是OAuth。
你可以把它想象成酒店的钥匙卡，不过是应用程序。如果你有酒店钥匙卡，你就可以进入你的房间。你怎么弄到酒店房卡?你必须在前台做一个认证过程来获得它。通过身份验证并获得钥匙卡之后，您就可以访问整个酒店的资源。
OAuth定义了四个角色:
资源所有者:通常是用户自己
客户机:请求访问资源服务器的应用程序
资源服务器:服务器托管受保护的数据(例如Facebook托管您的个人资料和个人信息)
授权服务器:向客户端发出访问令牌的服务器。这个令牌将用于客户机请求资源服务器。
下面是OAuth2流程的图表。
让我们考虑这个例子:
1、Spotify想从你的facebook账户访问你的好友列表。
2、你被Spotify重定向到授权服务器(在这种情况下是facebook)
3、如果授权访问，授权服务器会在回调响应中向客户端(Spotify)发送一个授权码。
4、然后，该代码根据Facebook和Spotify之间的访问令牌进行交换。
5、现在Spotify可以使用这个访问令牌来查询资源服务器(Facebook)并检索你的朋友列表。
需要注意的一点是，用户永远不会看到访问令牌，它将存储在会话中。授权服务器还发送其他信息，如令牌生存期和刷新令牌。
三、OpenID连接
OpenID Connect是OAuth 2.0协议之上的简单身份层，该协议扩展了OAuth2，并允许“联邦认证”。
OpenID Connect流程流类似于OAuth2授权流程，主要区别在于允许用户身份验证的“id-token”。
请注意，联邦身份验证与委托授权完全不同。让我们再以Facebook和Spotify为例
1、联邦认证是登录到Spotify使用你的facebook凭据。
2、授权是外部应用程序访问资源的能力。在这种情况下，Spotify试图访问你的facebook好友列表，并将其导入Spotify。
总结一下，这里是一个总结了所有三种协议/框架的表格。
