OAuth允许网站和服务在用户之间共享资产。它已被广泛接受，但请注意其漏洞。

自分布式个人计算机网络开始以来，要破解的最棘手的计算机安全问题之一就是在多台计算机之间提供无缝的单点登录（SSO）访问体验，每台计算机都需要不相关的登录帐户才能访问其服务，并且内容。尽管仍无法在整个Internet上完全实现，但现在可以使用一次物理登录访问无数个完全不相关的网站。您可以使用密码，电话，数字证书，生物特征，双因素身份验证（2FA）或多因素身份验证（MFA）SSO解决方案登录到一个位置，而不必整天放置另一个访问凭据来进行访问一堆其他的。我们非常感谢OAuth。

OAuth定义

OAuth是一种开放标准的授权协议或框架，描述了不相关的服务器和服务如何安全地允许对其资产进行身份验证的访问，而无需实际共享初始的，相关的，单一的登录凭据。用身份验证的话来说，这就是安全的，第三方的，用户代理的，委托的授权。

OAuth历史记录

OAuth由Twitter，Google和其他公司一开始创建并得到大力支持，OAuth在2010年以RFC 5849作为开放标准发布，并迅速被广泛采用。在接下来的两年中，它进行了实质性修订，OAuth的2.0版本于2012年作为RFC 6749发布。尽管2.0版由于以下所述的多种原因而受到广泛批评，但它却获得了更大的普及。今天，您可以添加Amazon，Facebook，Instagram，LinkedIn，Microsoft，Netflix，Paypal以及其他采用者的互联网列表。

OAuth范例

OAuth的最简单示例是，当您登录网站时，它提供了一个或多个使用其他网站/服务的登录名进行登录的机会。然后，您单击链接到另一个网站的按钮，另一个网站对您进行身份验证，然后使用从第二个网站获得的许可，您最初连接的网站将在您自己身上进行登录。

另一个常见的OAuth案例示例可能是用户通过电子邮件将云存储的文件发送给另一个用户，而该云存储和电子邮件系统除了不支持OAuth框架（例如Google Gmail和Microsoft OneDrive），否则是不相关的。当最终用户将文件附加到他们的电子邮件并浏览以选择要附加的文件时，可以在后台使用OAuth，以使电子邮件系统无缝地进行身份验证并浏览到受保护的文件，而无需再次登录文件存储系统。另一个示例（在OAuth 2.0 RFC中给出）是最终用户使用第三方打印服务来打印存储在不相关的Web服务器上的图片文件。

在所有情况下，最终用户都将两个或多个服务用于一个事务，并且每个最终用户都希望不要因为他们认为是单个事务而要求第二次登录。为了使OAuth（最终用户的客户端软件，例如浏览器）正常工作，所涉及的服务和身份验证提供程序必须支持正确版本的OAuth（1.0与2.0）。

OAuth解释

尝试了解OAuth时，记住OAuth方案几乎总是代表两个不相关的站点或服务，这些站点或服务试图代表用户或他们的软件来完成某件事可能会有所帮助。这三者必须共同努力，涉及完成交易的多个批准才能获得授权。

记住OAuth特别是关于授权，而不是直接关于认证，这也很有帮助。认证是用户/对象通过提供密码或其他唯一拥有或提供的要素来证明其对提供的身份的所有权的过程。授权是让主体在成功进行身份验证后（通常在其他地方）访问资源的过程。许多人认为OAuth代表开放式身份验证，但通过将其视为开放式AUTHorization来理解它会更有帮助。

早期的实现者将OAuth描述为类似于汽车的代客钥匙，可用于允许代客临时驾驶和停放汽车，但它不允许持有人像普通钥匙一样进行完全，无限制的访问。取而代之的是，汽车只能行驶几英里，不能进入后备箱或锁上杂物箱，并且可能有许多其他限制。OAuth本质上允许用户通过他们之前已成功进行身份验证的身份验证提供程序，为另一个网站/服务提供有限的访问身份验证令牌，以授权其他资源。

此外，OAuth 2.0是框架，而不是协议（例如1.0版）。就像所有汽车制造商都同意代客如何自动请求，接收和使用代客钥匙，以及这些代客钥匙的外观一般。与全功能键相比，代客钥匙的功能将取决于每个汽车制造商。就像现实生活中一样，代客和车主不需要关心一切如何运作。他们只是希望在交出钥匙时，一切都能尽可能无缝地进行。

OAuth的运作方式

假设用户已经登录到一个网站或服务（OAuth仅使用HTTPS起作用）。然后，用户启动需要访问另一个不相关的站点或服务的功能/交易。发生以下情况（大大简化了）：

1. 第一个网站使用OAuth代表用户连接到第二个网站，并提供用户的经过验证的身份。
2. 第二个站点生成一个一次性令牌和一个一次性秘密，该一次性令牌和一次性秘密对于交易和相关方而言是唯一的。
3. 第一个站点将此令牌和秘密提供给初始用户的客户端软件。
4. 客户端的软件向其授权提供者（可以是也可以不是第二个站点）提供请求令牌和机密。
5. 如果尚未向授权提供者进行身份验证，则可能会要求客户端进行身份验证。身份验证后，要求客户端将授权交易批准到第二个网站。
6. 用户在第一个网站上批准（或他们的软件静默批准）特定的交易类型。
7. 为用户提供了批准的访问令牌（注意，它不再是请求令牌）。
8. 用户将批准的访问令牌提供给第一个网站。
9. 第一网站将访问令牌提供给第二网站，以代表用户身份验证。
10. 第二个网站允许第一个网站代表用户访问其网站。
11. 用户看到成功完成交易。
12. OAuth并不是第一个代表最终用户以这种方式工作的身份验证/授权系统。实际上，许多身份验证系统（尤其是Kerberos）的工作方式相似。OAuth的特别之处在于它可以跨网络工作并被广泛采用。由于以前的尝试失败（由于各种原因），它的采用率很高。

尽管不那么简单，但是Web编码人员似乎很容易理解所涉及的事务。使网站与OAuth兼容可以在几小时到一天之内完成（如果您之前做过，则要快得多）。只需付出一点点额外的努力，就可以将经过身份验证的网站访问扩展到数亿个其他用户。无需网站包含自己的身份验证系统即可扩展到巨大的比例。您可以在此处找到单个HTTP事务数据包的示例。

OAuth与OpenID

在与OAuth相同的上下文中，您可能还听说过其他几种安全技术，其中之一就是OpenID。从根本上讲，两者之间的区别很容易理解。还记得我们上面说过的OAuth中的auth代表授权而不是认证吗？那么，OpenID的是关于认证：作为在计算器上一个评论员简洁地把它：“OpenID是人类登录到机器，OAuth是针对机器登录到代表人类的机器。”

OpenID于2005年问世，当时它是一种登录当时流行的LiveJournal博客网站的方法，但随后迅速传播到其他网站。在Web 2.0的早期，其思想是OpenID不会作为多个网站的多次登录，而是作为一个登录帐户来证明用户的身份。但是实际上，OpenID在开发人员方面很难实现，并且从未真正引起用户的青睐，特别是在该领域存在竞争的情况下。到2011年，OpenID成为了又一家公司，并且Wired宣布“没有人使用OpenID的主要原因是Facebook Connect做同样的事情并且做得更好。每个人都知道Facebook是什么，比起一些模糊，无法识别的叫做OpenID的事物，更容易理解Facebook正在处理您的身份。” （事实证明，Facebook Connect也不是世界领先者，但至少人们知道Facebook是什么。）

不过，这还不是故事的结局。2014年，发布了OpenID Connect，将OpenID重塑为OAuth的身份验证层。在这个领域，OpenID找到了一个利基市场，而这两种技术现在在许多实现中都可以相互补充。

OAuth与SAML

安全断言标记语言（SAML）是另一种与OAuth相同的技术。严格来说，名称SAML是指XML变体语言，但该术语也可以涵盖构成开放SAML标准一部分的各种协议消息和配置文件。SAML描述了一种框架，它允许一个计算机执行两者的认证和授权代表的一个或多个其它计算机，不像OAuth的，这就需要像ID连接的附加层，以执行认证。SAML可以自己提供单点登录功能。

SAML比OAuth年代久远，事实上，OAuth创建背后的驱动因素之一是SAML之类的XML协议开始流行。OAuth使用重量较轻的JSON编码数据，因此对移动设备具有更好的支持。实际上，SAML更常用于企业应用程序-例如，Salesforce将其用于单点登录-而OAuth更常在开放Internet上使用。

OAuth2

没有完善的通用互联网范围的身份验证标准。由于版本1.0和2.0之间发生了巨大变化，因此OAuth特别容易受到攻击。在许多方面，OAuth2用户是不太安全的，更复杂，比1.0版本更少规定。2.0版的创建者致力于使OAuth在站点和设备之间更具互操作性和灵活性。他们还介绍了令牌过期的概念，该概念在1.0版中不存在。无论目的如何，许多原始的创建者和支持者都举起了手，不支持2.0版。

所做的更改非常重要，以至于2.0版与1.0版不兼容，甚至2.0版的不同实现也可能无法无缝地协同工作。但是，没有什么阻止网站同时支持1.0和2.0的，尽管2.0的创建者出于所有网站完全替代1.0版本的目的而发布了该网站。

OAuth 2.0的最大批评之一是该标准有意不直接定义或支持加密，签名，客户端验证或通道绑定（将特定会话或事务绑定到特定客户端和服务器）。相反，OAuth希望实施者使用外部保护协议（如传输层安全性（TLS））来提供这些功能。

OAuth安全吗？

TLS可以提供所有这些保护，但是实现者必须全方位地要求使用它。编码人员和用户应注意确保OAuth在TLS保护内运行。开发人员可以实施代码来强制使用TLS，并且用户应该意识到，无论何时开始要求他们输入身份验证凭据，都在使用TLS（就像他们应该在任何时候输入凭据一样）。

由于缺乏固有的安全性绑定，流氓网站可能会在要求用户向授权提供者进行身份验证的过程的一部分期间，仿冒用户的合法凭据。例如，用户正在使用第一项服务，并选择了将OAuth交易强制用于第二项服务的功能。第一个网站可能会伪造第二个网站，而第二个网站通常会进行用户身份验证。流氓网站随后可以收集用户的身份验证凭据，并做出响应，就好像OAuth交易已成功进行一样。

这不仅是理论上的威胁。在2017年第二季度，成功地窃取了100万个Google帐户。用户的防御措施是确保在提示输入凭据时，他们在合法的第二网站的域中输入凭据，并避免使用模糊的第一网站。在所有网站上都没有一种完全安全，被普遍接受的SSO，但是有了OAuth，我们就越来越近了。

参考

What is OAuth? How the open authorization framework works