OAuth 2.0：优点和用例 – 为什么？

任何人都可以解释OAuth2有什么好处，为什么我们应该实现它？ 我问，因为我有点困惑 – 这是我目前的想法：

OAuth1（更准确地说是HMAC）的请求看起来合乎逻辑，易于理解，容易开发，真的很安全。

相反，OAuth2会带来授权请求​​，访问令牌和刷新令牌，并且您必须在会话开始时发出3个请求才能获取您之后的数据。 即使如此，当令牌过期时，您的一个请求最终会失败。

而要获得另一个访问令牌，则使用与访问令牌同时传递的刷新令牌。 从安全的angular度来看，这是否使访问令牌失效？

另外，正如/ r / netsec最近展示的那样，SSL并不是完全安全的，所以把所有东西都推到TLS / SSL而不是安全的HMAC上让我感到困惑。

OAuth认为，这不是100％的安全，而是要发布和完成。 从提供商的angular度来看，这听起来不太可能。 当草案提到6个不同的stream程时，我可以看到草案想要达到什么目的，但是这只是不合适的。

我觉得这可能比我更努力去理解它的好处和推理，而不是实际上不喜欢它，所以这可能是一个不必要的攻击，如果这看起来像一个咆哮，可惜。

Answer 1

背景：我已经为OAuth 1.0a和2.0编写了客户端和服务器堆栈。

OAuth 1.0a和2.0都支持双向authentication ，在这种authentication中 ，服务器可以确保用户的身份，并且支持三方authentication ，服务器由用户身份的内容提供者保证。 三段身份validation是授权请求和访问令牌发挥作用的地方，需要注意的是，OAuth 1也具有这些function。

复杂的一个：三脚authentication

OAuth规范的一个要点是内容提供者 （例如Facebook，Twitter等）向服务器 （例如希望代表客户端与内容提供者交谈的Web应用）保证客户端具有某种身份。 三脚authentication提供的是在没有客户或服务器需要知道该身份的细节 （例如用户名和密码）的情况下这样做的能力。

没有（？）太深入OAuth的细节：

1. 客户端向服务器提交授权请求，validation客户端是否是其服务的合法客户端。
2. 服务器将客户端redirect到内容提供者以请求访问其资源。
3. 内容提供者validation用户的身份，并经常请求他们的权限来访问资源。
4. 内容提供者将客户端redirect回服务器，通知其成功或失败。 该请求包含成功的授权码。
5. 服务器向内容提供商发出带外请求，并交换访问令牌的授权码。

服务器现在可以通过传递访问令牌来代表用户向内容提供者发送请求。

每个交换（客户端 – >服务器，服务器 – >内容提供者）都包含对共享密钥的validation，但由于OAuth 1可以通过未encryption的连接运行，因此每个validation都无法通过线路传递该密钥。

就像你所说的那样，HMAC已经完成了。 客户端使用它与服务器共享的秘密签署其授权请求的参数。 服务器接受参数，用客户端密钥自己签名，并能够看到它是否是合法的客户端（在上面的步骤1中）。

这个签名要求客户端和服务器端对参数的顺序达成一致（所以他们签名的是完全相同的string），关于OAuth 1的主要抱怨之一是它需要服务器和客户端进行sorting，标志相同。 这是繁琐的代码，无论是正确的，或者你得到401 Unauthorized帮助。 这增加了写作客户的障碍。

通过要求授权请求通过SSL运行，OAuth 2.0不再需要参数sorting和签名。 客户端将其秘密传递给服务器，直接validation服务器。

在服务器 – >内容提供者连接中存在相同的要求，并且因为这是删除写入访问OAuth服务的服务器的一个障碍的SSL。

这使得事情在上面的步骤1,2和5中变得更容易。

所以在这一点上我们的服务器有一个永久访问令牌，这是一个用户名/密码等同于用户。 它可以通过将该访问令牌作为请求的一部分（作为查询参数，HTTP头或POST表单数据）传递给内容提供者，代表用户向内容提供者发送请求。

如果只通过SSL访问内容服务，我们就完成了。 如果它通过普通的HTTP可用，我们希望以某种方式保护永久访问令牌。 任何嗅探连接的人都可以永久访问用户的内容。

在OAuth 2中解决的方法是使用刷新令牌 。 刷新令牌变成了相当于永久密码的密码，并且只通过SSL传输 。 当服务器需要访问内容服务时，它将刷新令牌交换短期访问令牌。 这样，所有可探测的HTTP访问都将使用一个将过期的令牌。 Google在其OAuth 2 API上使用了5分钟的过期时间。

所以除了刷新令牌之外，OAuth 2简化了客户端，服务器和内容提供者之间的所有通信。 而刷新令牌仅用于在未encryption访问内容时提供安全性。

双腿authentication

但有时候，服务器只需要控制对自己内容的访问。 双腿authentication允许客户端直接使用服务器来authentication用户。

OAuth 2标准化了OAuth 1中广泛使用的一些扩展。 我最熟悉的一个是Twitter推出的xAuth 。 您可以在OAuth 2中将其视为资源所有者密码凭证 。

实质上，如果您可以使用用户凭据（用户名和密码）信任客户端，则可以直接与内容提供者交换访问令牌。 这使得OAuth在移动应用上更加有用 – 采用三方authentication，您必须embeddedHTTP视图以处理内容服务器的授权过程。

使用OAuth 1，这不是官方标准的一部分，并且需要与所有其他请求相同的签名过程。

我刚刚使用Resource Owner Password Credentials来实现OAuth 2的服务器端，并且从客户端的angular度来看，获取访问令牌变得简单：从服务器请求访问令牌，将客户端ID /秘密作为HTTP Authorization头传递，用户的login名/密码作为表单数据。

优点：简单

所以从实现者的angular度来看，我在OAuth 2中看到的主要优点是复杂性降低。 它不需要请求签名程序，这并不困难，但肯定是很烦琐的。 它大大减less了作为一个服务的客户所需的工作，这是你最想要减轻痛苦的地方（在现代的移动世界中）。 服务器 – >内容提供者端的复杂性降低，使其在数据中心中的可扩展性更高。

并将其标准化为OAuth 1.0a的一些扩展（如xAuth），现在已经广泛使用。

Answer 2

我会以不同的方式回答这个问题，我会非常精确和简短，主要是因为@Peter T回答了这一切。

我从这个标准看到的主要收获是尊重两个原则：

1. 关注点分离。
2. 从通常服务于业务的Web应用程序中分离身份validation。

通过这样做，

1. 您可以实施单一login的替代scheme：如果您有多个信任一个STS的应用程序。 我的意思是，所有应用程序都有一个用户名。
2. 您可以启用您的Web应用程序（客户端）访问属于该用户且不属于Web应用程序（客户端）的资源。
3. 您可以将身份validation过程委托给您信任的第三方，从不担心用户身份validation。