OAuth 2.0 : Benefits and use cases — why?

Question

谁能解释一下 OAuth2 的优点以及我们为什么要实现它？我问是因为我对此有点困惑——这是我目前的想法:

OAuth1(更准确地说是 HMAC)请求看起来合乎逻辑、易于理解、易于开发并且非常非常安全。

相反，OAuth2 带来了授权请求、访问 token 和刷新 token ，您必须在 session 开始时发出 3 个请求才能获取所需的数据。即便如此，当 token 过期时，您的一个请求最终会失败。

要获得另一个访问 token ，您可以使用与访问 token 同时传递的刷新 token 。从安全的角度来看，这是否会使访问 token 变得无用？

另外，正如/r/netsec 最近表明的那样，SSL 并非完全安全，因此将所有内容都放到 TLS/SSL 而不是安全的 HMAC 上的做法让我感到困惑。

OAuth 认为它不是 100% 安全，而是让它发布和完成。从提供商的角度来看，这听起来并不完全有希望。当草案提到 6 种不同的流程时，我可以看到它试图实现的目标，但它在我的脑海中并不适合。

我认为这可能更多是我在努力理解它的好处和推理而不是真正不喜欢它，所以这可能是一种毫无根据的攻击，如果这看起来像是咆哮，我很抱歉。

Answer 1

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

OAuth 1.0a 和 2.0 都支持 双足认证 ，其中服务器确保用户的身份，以及 三足认证 ，其中服务器由用户身份的内容提供者保证。三足认证是授权请求和访问 token 发挥作用的地方，重要的是要注意 OAuth 1 也有这些。

复杂一:三足认证

OAuth 规范的一个要点是针对 内容提供商 (例如 Facebook、Twitter 等)以确保 服务器 (例如，希望代表客户端与内容提供者交谈的 Web 应用程序)客户端具有某些身份。三足认证所提供的是无需客户端或服务器知道该身份的详细信息(例如用户名和密码)的能力。

没有 (?) 深入了解 OAuth 的细节:

客户端向服务器提交授权请求，服务器验证客户端是其服务的合法客户端。

服务器将客户端重定向到内容提供者以请求访问其资源。

内容提供者验证用户的身份，并经常请求他们访问资源的许可。

内容提供者将客户端重定向回服务器，通知它成功或失败。此请求包含成功时的授权代码。

服务器向内容提供者发出带外请求并交换访问 token 的授权代码。

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

每个交换(客户端->服务器、服务器->内容提供者)都包括对共享 secret 的验证，但由于 OAuth 1 可以在未加密的连接上运行，因此每次验证都无法通过网络传递 secret 。

正如您所指出的，这已经通过 HMAC 完成了。客户端使用它与服务器共享的 secret 来签署其授权请求的参数。服务器接受参数，用客户端的 key 对它们本身进行签名，并能够查看它是否是合法客户端(在上面的步骤 1 中)。

此签名要求客户端和服务器就参数的顺序达成一致(因此他们签署的是完全相同的字符串)，并且对 OAuth 1 的主要提示之一是它要求服务器和客户端都进行排序和签名相同。这是繁琐的代码，要么正确，要么你得到 401 Unauthorized几乎没有帮助。这增加了编写客户端的障碍。

通过要求授权请求通过 SSL 运行，OAuth 2.0 完全不需要参数排序和签名。客户端将其 secret 传递给服务器，服务器直接对其进行验证。

服务器-> 内容提供程序连接中存在相同的要求，并且因为 SSL 消除了编写访问 OAuth 服务的服务器的一个障碍。

这使上面的步骤 1、2 和 5 中的事情变得容易得多。

所以此时我们的服务器有一个永久的访问 token ，它是用户的用户名/密码等价物。它可以通过将访问 token 作为请求的一部分(作为查询参数、HTTP header 或 POST 表单数据)传递来代表用户向内容提供者发出请求。

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

在 OAuth 2 中解决的方法是使用 刷新 token .刷新 token 成为等效的永久密码，并且它只通过 SSL 传输。当服务器需要访问内容服务时，它会将刷新 token 交换为短期访问 token 。这样，所有可嗅探的 HTTP 访问都是使用将过期的 token 进行的。 Google 在其 OAuth 2 API 上使用了 5 分钟的过期时间。

因此，除了刷新 token 之外，OAuth 2 还简化了客户端、服务器和内容提供者之间的所有通信。刷新 token 仅用于在未加密访问内容时提供安全性。

两条腿认证

但有时，服务器只需要控制对其自身内容的访问。两条腿认证允许客户端直接向服务器认证用户。

OAuth 2 标准化了一些广泛使用的 OAuth 1 扩展。我最了解的一个是 Twitter 介绍的 xAuth .您可以在 OAuth 2 中看到它为 Resource Owner Password Credentials .

本质上，如果您可以使用用户的凭据(用户名和密码)信任客户端，则他们可以直接与内容提供者交换这些凭据以获取访问 token 。这使得 OAuth 在移动应用程序上更有用——通过三足认证，你必须嵌入一个 HTTP View 来处理与内容服务器的授权过程。

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

我刚刚使用 Resource Owner Password Credentials 实现了 OAuth 2 的服务器端，从客户端的角度来看，获取访问 token 变得很简单:从服务器请求访问 token ，将客户端 ID/ secret 作为 HTTP 授权 header 和用户的登录名/密码作为表单数据。

优点:简单

因此，从实现者的角度来看，我在 OAuth 2 中看到的主要优势在于降低了复杂性。它不需要请求签名程序，这并不完全困难，但肯定很繁琐。它大大减少了充当服务客户端所需的工作，而这正是(在现代移动世界中)您最希望最大程度减少痛苦的地方。服务器->内容提供商端的复杂性降低，使其在数据中心更具可扩展性。

并且它将 OAuth 1.0a 的一些扩展(如 xAuth)编入标准，这些扩展现在被广泛使用。