OAuth 2.0：优点和用例 - 为什么？
任何人都可以解释一下OAuth2的优点以及我们为什么应该实现它吗？ 我问，因为我有点困惑 - 这是我目前的想法：
OAuth1（更准确地说是HMAC）请求看起来合乎逻辑，易于理解，易于开发并且非常安全。
相反，OAuth2会提供授权请求，访问令牌和刷新令牌，并且您必须在会话开始时发出3个请求才能获取您之后的数据。 即便如此，当令牌过期时，您的一个请求最终会失败。
为了获得另一个访问令牌，您使用与访问令牌同时传递的刷新令牌。 从安全的角度来看，这会使访问令牌失效吗？
另外，正如/ r / netsec最近展示的那样，SSL并非全部都是安全的，因此推动将所有内容都纳入TLS / SSL而不是安全的HMAC会让我感到困惑。
OAuth认为它不是100％的安全性，而是将其发布并完成。 从提供商的角度来看，这听起来不太可能。 草稿提到6种不同的流程时，我可以看到草稿想要达到什么效果，但这只是不适合我的脑袋。
我认为这可能比我更难以理解它的好处和推理，而不是实际上不喜欢它，所以这可能是一种无理的攻击，如果这看起来像一个咆哮，可惜。
背景：我为OAuth 1.0a和2.0编写了客户端和服务器堆栈。
OAuth 1.0a和2.0均支持双向认证 ，即服务器可确保用户身份，以及支持三方认证 ，其中服务器由用户身份的内容提供商保证。 三段身份验证是授权请求和访问令牌发挥作用的地方，需要注意的是OAuth 1也具有这些功能。
复杂的一个：三脚认证
OAuth规范的一个重点是内容提供者 （例如Facebook，Twitter等）向服务器 （例如希望代表客户端与内容提供者交谈的Web应用程序）确保客户端具有某种身份。 三脚认证提供的是在没有客户或服务器需要知道该身份的细节（例如用户名和密码）的情况下这样做的能力。
没有（？）太深入OAuth的细节：
服务器现在可以通过传递访问令牌来代表用户向内容提供者发送请求。
每个交换（客户端 - >服务器，服务器 - >内容提供者）都包含对共享密钥的验证，但由于OAuth 1可以通过未加密的连接运行，因此每个验证都无法通过线路传递该密钥。
正如你所说，这已经完成，与HMAC。 客户端使用它与服务器共享的秘密签署其授权请求的参数。 服务器接受参数，用客户端密钥自己签名，并能够看到它是否是合法的客户端（在上面的步骤1中）。
这个签名要求客户端和服务器同意参数的顺序（所以他们签署的是完全相同的字符串），而OAuth 1的主要抱怨之一是它需要服务器和客户端进行排序和标志相同。 这是繁琐的代码，无论是正确的，或者你得到401 Unauthorized ，没有什么帮助。 这增加了写作客户的障碍。
通过要求授权请求通过SSL运行，OAuth 2.0完全不需要参数排序和签名。 客户端将其秘密传递给服务器，直接验证服务器。
服务器 - >内容提供者连接中存在相同的要求，并且因为这是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，这不是官方标准的一部分，并且需要与所有其他请求相同的签名过程。
我刚刚使用资源所有者密码凭证实现了OAuth 2的服务器端，并且从客户端的角度来看，获取访问令牌变得很简单：从服务器请求访问令牌，将客户端ID /密钥作为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标识（OIDC）和带有可插入连接器的OAuth 2.0 Provider。
从这个职位vonc回答
我会以不同的方式回答这个问题，我会非常精确和简短，主要是因为@Peter T回答了所有问题。
我从这个标准看到的主要收获是尊重两个原则：
通过这样做，
上一篇: OAuth 2.0: Benefits and use cases — why?
下一篇: How would an efficient OAuth2.0 server / provider work?