有谁能解释一下OAuth2的优点以及为什么我们应该实现它吗？我这么问是因为我对它有点困惑-以下是我目前的想法：
OAuth 1（更准确地说是HMAC）请求看起来很有逻辑，易于理解，易于开发，而且非常非常安全。
相反，OAuth2带来了授权请求，访问令牌和刷新令牌，您必须在会话开始时发出3个请求才能获得您想要的数据。即使这样，当令牌过期时，您的请求最终也会失败。
为了获得另一个访问令牌，您使用了与访问令牌同时传递的刷新令牌。从安全的Angular 来看，这是否会使访问令牌无效？
另外，正如/r/netsec最近所展示的那样，SSL并不完全安全，因此将所有内容都放在TLS/SSL而不是安全的HMAC上的做法让我感到困惑。
OAuth认为这不是100%的安全，而是发布和完成。从提供商的Angular 来看，这听起来并不完全有希望。当提到6个不同的流时，我可以看到草案试图实现的目标，但它只是不适合在我的脑海中。
我想这可能更多的是我在努力理解它的好处和理由，而不是实际上不喜欢它，所以这可能是一个毫无根据的攻击，对不起，如果这看起来像一个咆哮。
3条答案
按热度按时间gjmwrych1#
背景：我已经为OAuth 1.0a和2.0编写了客户端和服务器堆栈。
OAuth 1.0a和2.0都支持两条腿的身份验证，其中服务器确保用户的身份，以及三条腿的身份验证，其中服务器由内容提供商确保用户的身份。三条腿的身份验证是授权请求和访问令牌发挥作用的地方，重要的是要注意OAuth 1也有这些。
复杂一个：三足认证
OAuth规范的一个要点是针对内容提供者（例如Facebook、Twitter、等）以确保服务器（例如，希望代表客户端与内容提供商对话的Web应用程序）客户端具有某种身份。三条腿身份验证提供的是在客户端或服务器 * 不需要知道该身份的详细信息 * 的情况下执行此操作的能力。（例如用户名和密码）。
在不深入OAuth细节的情况下：
1.客户端向服务器提交授权请求，服务器验证客户端是否是其服务的合法客户端。
1.服务器将客户端重定向到内容提供商以请求访问其资源。
1.内容提供者验证用户的身份，并且通常请求他们访问资源的许可。
1.内容提供者将客户端重定向回服务器，通知它成功或失败。此请求包含成功时的授权代码。
1.服务器向内容提供商发出带外请求，并将授权码交换为访问令牌。
服务器现在可以通过传递访问令牌来代表用户向内容提供商发出请求。
每个交换（客户端-〉服务器，服务器-〉内容提供者）都包括对共享密钥的验证，但是由于OAuth 1可以在未加密的连接上运行，因此每个验证都不能通过网络传递密钥。
客户端使用它与服务器共享的密钥来签署其授权请求的参数。服务器获取参数，使用客户端的密钥自己签署它们，并且能够查看它是否是合法的客户端（在上面的步骤1中）。
这种签名要求客户端和服务器端都同意参数的顺序（所以他们签署的是完全相同的字符串），而OAuth 1的主要抱怨之一是它要求服务器端和客户端都以相同的方式进行排序和签名。这是一段繁琐的代码，要么是正确的，要么你在没有帮助的情况下就得到了
401 Unauthorized。这增加了编写客户端的障碍。OAuth 2.0要求授权请求在SSL上运行，从而完全消除了参数排序和签名的需要。客户端将其秘密传递给服务器，服务器直接对其进行验证。
在server-〉content provider连接中也存在相同的需求，因为这是SSL，所以它消除了编写访问OAuth服务的服务器的一个障碍。
这使得上面的步骤1、2和5中的事情变得容易得多。
因此，在这一点上，我们的服务器有一个永久的访问令牌，这是用户的用户名/密码等效。它可以通过将访问令牌作为请求的一部分（作为查询参数，HTTP头或POST表单数据）传递给内容提供者，代表用户向内容提供者发出请求。
如果内容服务只能通过SSL访问，我们就完成了。如果它可以通过普通HTTP访问，我们希望以某种方式保护永久访问令牌。任何嗅探连接的人都可以永远访问用户的内容。
在OAuth 2中解决这个问题的方法是使用刷新令牌。刷新令牌成为永久密码等效物，并且它 * 只通过SSL* 传输。当服务器需要访问内容服务时，它将刷新令牌交换为短期访问令牌。这样，所有可嗅探的HTTP访问都将使用将过期的令牌进行。Google在他们的OAuth 2 API上使用了5分钟的过期时间。
因此，除了刷新令牌之外，OAuth 2简化了客户端、服务器和内容提供者之间的所有通信。刷新令牌的存在只是为了在未加密的内容访问时提供安全性。
两条腿认证
有时候，服务器只需要控制对它自己内容的访问，两条腿的身份验证允许客户端直接向服务器验证用户。
OAuth 2标准化了OAuth 1的一些扩展，这些扩展被广泛使用。我最熟悉的一个是Twitter引入的xAuth。你可以在OAuth 2中看到它作为资源所有者密码凭据。
从本质上讲，如果你可以信任客户端的用户凭证（用户名和密码），他们可以直接与内容提供商交换这些凭证以获得访问令牌。这使得OAuth在移动的应用程序上更加有用-使用三脚身份验证，你必须嵌入HTTP视图以处理与内容服务器的授权过程。
在OAuth 1中，这不是官方标准的一部分，并且需要与所有其他请求相同的签名过程。
我刚刚用Resource Owner Password Credentials实现了OAuth 2的服务器端，从客户端的Angular 来看，获取访问令牌变得很简单：从服务器请求访问令牌，将客户端id/secret作为HTTP Authorization头传递，将用户的登录名/密码作为表单数据传递。
优势：简单
因此，从实现者的Angular 来看，我在OAuth 2中看到的主要优点是降低了复杂性。它不需要请求签名过程，这并不困难，但肯定是繁琐的。它大大减少了作为服务客户端所需的工作，这就是为什么OAuth 2可以在一个特定的服务中运行。（在现代的移动的世界中）你最想最小化痛苦。服务器-〉内容提供商端的复杂性降低，使其在数据中心更具可扩展性。
它将OAuth 1.0a的一些扩展（如xAuth）编入标准，这些扩展现在已被广泛使用。
8fsztsew2#
首先，正如OAuth身份验证中明确指出的
OAuth 2.0不是认证协议。
在用户访问应用程序的上下文中，身份验证会告诉应用程序当前用户是谁以及他们是否存在。完整的身份验证协议可能还会告诉您有关此用户的许多属性，例如唯一标识符，电子邮件地址，以及当应用程序说“早安”时如何称呼他们。
然而，OAuth并没有告诉应用程序这些。OAuth绝对没有说任何关于用户的信息，也没有说用户如何证明他们的存在，甚至没有说他们是否还在那里。就OAuth客户端而言，它要求一个令牌，得到一个令牌，并最终使用该令牌访问一些API。它不知道谁授权了应用程序，甚至不知道是否有用户。
使用OAuth进行用户身份验证有一个标准：OpenID Connect，与OAuth2兼容。
OpenID Connect ID令牌是一个签名的JSON Web令牌（JWT），它与常规的OAuth访问令牌沿着提供给客户端应用程序。ID令牌包含一组关于身份验证会话的声明，包括用户的标识符（sub）、发布令牌的身份提供者的标识符（iss）以及为其创建此令牌的客户端的标识符（aud）。
在Go中，您可以查看coreos/dex，这是一个OpenID Connect Identity（OIDC）和OAuth 2.0 Provider with Pluggable Connector。
此分类下一篇：vonc
sxpgvts33#
我会稍微不同地回答这个问题，我会非常精确和简短，主要是因为@Peter T回答了这一切。
我从这个标准中看到的主要收获是尊重两个原则：
1.关注点分离。
1.将授权与通常服务于业务的Web应用程序分离。
通过这样做，
1.您可以实现Single SignOn的替代方案：如果您有多个应用程序信任一个STS，我的意思是，所有应用程序都有一组凭证。
1.您可以使您的Web应用程序（客户端）访问属于您的资源，而不属于Web应用程序（客户端）。
1.您可以将授权过程委托给您信任的第三方，而不必担心用户真实性验证。