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