作者：Jaime Lightfoot spin.atomicobject.com May 30th, 2016
原文：Authentication and Authorization: OpenID vs OAuth2 vs SAML
原文链接：https://spin.atomicobject.com/2016/05/30/openid-oauth-saml/
我目前在 AO 的项目中得到了很多机会来了解网络安全，以及点击无处不在的 “使用Google/Facebook登录” 按钮时发生的情况。作为计算机开发人员和终端用户，我都希望应用程序安全而不会太难使用。
寻找适合我们的应用程序和客户安全策略，我们研究了 OpenID, OAuth2,和 SAML.。
授权和认证基础
我们的项目是一个单页面应用程序，将成为面向公众的网站。我们只想限制对注册用户的访问。此外，我们希望调整每个用户的体验，以及他们可以查看的数据量和类型，以及他们各自的角色和访问级别。
换句话说，我们希望能够验证和授权每个用户。认证意味着验证某人确实是他们自称的人。授权意味着决定某个用户应该能够访问哪些资源，以及应该允许他们对这些资源执行哪些操作。在我们的例子中，通常情况下，应用程序需要一点点。
通过 Facebook 或 Google 等网站，用户可以使用一组凭据登录到一个应用程序。然后可以使用这组相同的凭证登录相关的网站或应用程序（例如向您询问的网站，“使用Facebook或Google帐户注册？”）。
同样，企业可能有一个面向内部的员工门户，其中包含时间表，健康保险或公司新闻等内部网站链接。而不是要求员工在每个网站上登录，更好的解决方案是让员工登录门户，并让该门户自动向其他 Intranet 站点验证用户身份。这种被称为单点登录（SSO）的思想允许用户输入一个用户名和密码以访问多个应用程序。
好处对用户来说非常好。链接身份的使用意味着他们必须仅管理相关网站的一个用户名和密码。用户体验对他们来说更好，因为他们可以避免多次登录。用户（单一组）的凭证将存储在一个数据库中，而不是存储在多个数据库中的多个凭证（使用老实说，可能是重复的密码）。这也意味着各种应用程序的开发人员不必存储密码。相反，他们可以接受来自可信来源的身份证明或授权证明。
有多种解决方案来实现SSO。三种最常见的网络安全协议（撰写本文时）是OpenID，OAuth和SAML。实现和库已经以多种语言存在，并且使用标准化协议可以实现比定制解决方案更好的互操作性。
OpenID
OpenID 是一个开放的身份验证标准，由非盈利性 OpenID Foundation推广。截至2016年3月，互联网上有超过10亿支持 OpenID 的帐户，诸如 Google，WordPress，Yahoo 和 PayPal 等组织使用OpenId对用户进行身份验证。
用户必须通过 OpenID 身份提供商（例如 Google ）获得 OpenID 帐户。然后，用户将使用该帐户登录任何接受OpenID 身份验证的网站（依赖方）（认为YouTube或另一个接受Google帐户登录的网站）。 OpenID 标准为身份提供者和依赖方之间必须进行的通信提供了一个框架。
这种交换可以与边境口岸相比较。想象一下，Alice 是一位想要访问美国的加拿大公民。在边界，美国要求身份证明（她的护照）。由于美国政府相信加拿大政府准确地为其公民提供身份证明，因此美国接受爱丽丝的护照作为她身份的可靠证明，从而让她进入美国。在这个例子中，Alice 是最终用户，美国是依赖方，加拿大是身份提供者。
这种交换是有效的，因为爱丽丝可以向美国提供源自美国信任实体的身份证明。同样，依赖方（或用户试图登录的网站）必须信任将验证用户身份的OpenID身份提供商。
在一个网站上，交易所看起来像这样：
让我们回到想要登录到她的 MyBlogger 帐户（依赖方）的 Alice。 她导航到登录屏幕，在那里提供 “使用Google登录” 选项。 她点击它，MyBlogger启动与Google的关联并请求并收到关联句柄。 MyBlogger 然后将爱丽丝转发到 Google 登录页面。 她输入她的凭据，然后 Google 验证它们。 然后，她被重定向回 MyBlogger，并附上一个令牌，声明 Google 相信她是她自称的人（Alice）。 MyBlogger信任此令牌并为她创建一个会话。
注意：
- OpenID 技术上是用户拥有的URL（例如alice2016.openid.com），所以一些网站提供手动输入 OpenID 的选项。
- 最新版本的 OpenID 是 OpenID Connect，它结合了 OpenID 身份验证和 OAuth2 授权
- Facebook 之前使用OpenID，但后来转移到Facebook Connect。
OAuth2
相比之下，OAuth2是一个开放的授权标准。令人困惑的是，OAuth2 也是 OpenID Connect 的基础，OpenID Connect 在 OAuth2（授权）之上提供了OpenID（认证），以提供更完整的安全解决方案。 OpenID Connect（OIDC）创建于2014年初。该初级读本本身将专注于OAuth2，而不是 OIDC 的一部分。
OAuth2 提供安全的委托访问，这意味着称为客户端的应用程序可以代表用户在资源服务器上执行操作或访问资源，而无需用户与应用程序共享其凭据。 OAuth2 通过允许身份提供者向这些第三方应用程序颁发令牌并获得用户的批准来实现此目的。客户端然后使用该令牌代表用户访问资源服务器。
然而 Twitter 的 OAuth 指南 称OAuth2是一种认证标准。那么是什么给了？事实证明，授权可以用作伪认证的一种形式。
OAuth2 的授权用例可能如下：Alice离开城镇，她希望她的朋友 Bob 坐在家中。Alice 给了 Bob 房子钥匙，现在他有权进入房子。密钥授权他进入房屋，因为授权涉及用户应该访问哪些资源，以及他们可以用这些资源做什么。在这个比喻中，房主是用户，Bob是客户，门锁是身份提供者，而房子是资源服务器。
假设拥有房屋钥匙的人是房主，这可以被扭曲成伪认证用例。然而，正如我们可以看到 Bob 为 Alice 坐着一样，情况并非总是如此。
在线上，OAuth2 使用案例可能如下所示：Alic e在 NewApp 注册一个新帐户，并提供选项以查看她的哪些朋友已经使用 NewApp，以便与他们连接。有一个标签为 “从Facebook导入联系人” 的按钮。Alice点击该按钮，她被重定向到 Facebook 登录。Alice成功登录并询问她是否想要与NewApp分享她的 Facebook 好友列表。她点击是，并与令牌一起被转发回 NewApp。 NewApp现在拥有权限（通过令牌）可以访问 Alice 的好友列表，而不必直接与 NewApp 分享她的凭证。这消除了 NewApp 以 Alice 的名义登录 Facebook 并做她不想做的事情（发布状态更新，更改密码等）的风险。
SAML
SAML是这三者中最老的标准，最初于2001年开发，最近在2005年进行了重大更新。SAML 发音为“sam-el”，代表安全声明标记语言。这是一个提供认证和授权的开放标准。
与其他两个标准的术语相似，SAML 定义了一个委托人，即试图访问资源的最终用户。有一个服务提供者，它是委托人尝试访问的Web服务器。还有一个身份提供者，它是持有委托人身份和凭证的服务器。
美国/加拿大的比喻也可以在这里使用。Alice 希望从加拿大进入美国。美国希望核实她的身份或其他关于她的信息，或许她是否有有效的驾驶执照，允许她在美国开车） - 向加拿大提出关于 Alice 认证和/或授权信息的请求。加拿大的答复是将所要求的信息发送到所要求的地址，以及一些证明加拿大确实是信息的发送者。所有的隐喻最终都会被打破，但这种证明可能与以前一样，或者官方的政府文件或签证（涉及授权请求的地方）采取护照的形式。而且，和以前一样，该体系的前提是美国相信加拿大正在适当地颁发驾驶执照，签证等。
在我们的例子中，Alice 是主要的，美国是服务提供者，加拿大又是身份提供者。美国向加拿大提出的请求类似于一条 XML 消息，该消息说明正在请求什么信息，请求谁以及应该将响应返回给谁。加拿大的回应将被称为 SAML条款中的断言（类似于OpenID或OAuth2的令牌）。该断言可以包含关于认证，授权和/或属性（关于用户的特定信息，诸如电子邮件或电话号码）的声明。
SAML 2.0 规范定义了断言（如上所述）协议，这是断言请求和响应绑定，或者这些请求和响应如何使用标准通信方法（例如HTTP POST）在服务提供者和身份提供者之间发生;和配置文件，它们是各种用例的断言，协议和绑定的组合，如SSO。
SSO用例可能如下所示：Alice 是 Acme Corp.的经理。她访问 Acme Corp 的 Intranet 门户，在那里她使用她的凭证登录。登录后，她可以点击一些她可能感兴趣的链接（工资单，公司新闻，Salesforce等）。她点击 Salesforce链接，该链接包含关于 Alice 的 SAML 断言。她被转发到接收 SAML 断言的 Salesforce。 Salesforce 信任Acme Corp，因此相信这一说法。使用令牌中的信息，Alice 会自动登录，并根据断言中的属性向她显示相应的数据。
概要
表中总结了这三个选项。 我们的应用程序实现了 IdentityServer，一个实现 OAuth2 和 OpenID Connect 的.NET框架。
| OAuth2 | OpenId | SAML | |
|---|---|---|---|
| Token (or assertion) format | JSON or SAML2 | JSON | XML |
| Authorization? | Yes | No | Yes |
| Authentication? | Pseudo-authentication | Yes | Yes |
| Year created | 2005 | 2006 | 2001 |
| Current version | OAuth2 | OpenID Connect | SAML 2.0 |
| Transport | HTTP | HTTP GET and HTTP POST | HTTP Redirect (GET) binding, SAML SOAP binding, HTTP POST binding, and others |
| Security Risks | PhishingOAuth 2.0 does not support signature, encryption, channel binding, or client verification. Instead, it relies completely on TLS for confidentiality. | PhishingIdentity providers have a log of OpenID logins, making a compromised account a bigger privacy breach | XML Signature Wrapping to impersonate any user |
| Best suited for | API authorization | Single sign-on for consumer apps | Single sign-on for enterpriseNote: not well suited for mobile |