OAuth 2.0:好处和用例 - 为什么？

Question

任何人都可以解释OAuth2有什么好处以及为什么要实现它？我问,因为我对它有点困惑 - 这是我目前的想法:

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

相反,OAuth2会带来授权请求​​,访问令牌和刷新令牌,您必须在会话开始时发出3个请求才能获取您所追踪的数据.即便如此,当令牌过期时,您的一个请求最终会失败.

要获取另一个访问令牌,您可以使用与访问令牌同时传递的刷新令牌.从安全角度来看,这是否会使访问令牌徒劳无功？

另外,正如/ r/netsec最近所展示的那样,SSL并非完全安全,因此将所有内容都放到TLS/SSL而非安全HMAC上的努力让我感到困惑.

OAuth认为它不是100%的安全性,而是将其发布和完成.从提供商的角度来看,这听起来并不乐观.我可以看到草案在提到6种不同的流量时试图实现的目标,但它并没有在我脑海中融合在一起.

我认为可能更难以理解它的好处和推理而不是实际上不喜欢它,所以这可能是一种无根据的攻击,如果这看起来像是一种咆哮,那就很抱歉.

Answer 1

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

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

复杂的一个:三条腿认证

OAuth规范的一个要点是内容提供商(例如Facebook,Twitter等)确保服务器(例如,希望代表客户端与内容提供商交谈的Web应用程序)客户端具有某种身份.三脚认证提供的是能够在客户端或服务器不需要知道该身份的详细信息(例如用户名和密码)的情况下执行此操作.

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

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

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

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

正如您所指出的那样,HMAC已经完成了这项工作.客户端使用与服务器共享的密钥来为其授权请求签署参数.服务器获取参数,使用客户端密钥对其进行签名,并且能够查看它是否是合法客户端(在上面的步骤1中).

此签名要求客户端和服务器同意参数的顺序(因此它们签署完全相同的字符串),并且关于OAuth 1的主要抱怨之一是它需要服务器和客户端进行排序和同样的标志.这是一个繁琐的代码,要么是正确的,要么你得到的401 Unauthorized帮助很少.这增加了编写客户端的障碍.

通过要求授权请求通过SSL运行,OAuth 2.0完全不需要参数排序和签名.客户端将其秘密传递给服务器,服务器直接验证它.

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,这不是官方标准的一部分,并且需要与所有其他请求相同的签名过程.

我刚刚实施的OAuth 2的服务器端与资源所有者密码凭据,并从客户的角度来看,获得访问令牌变得简单:从服务器请求一个访问令牌,通过客户端ID /秘密作为HTTP Authorization头和用户的登录名/密码作为表单数据.

优点:简单

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

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

Answer 2

首先,如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

Answer 3

我会稍微不同地回答这个问题，我会非常精确和简短，主要是因为@Peter T 回答了所有问题。

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

1. 关注点分离。
2. 将身份验证与通常服务于业务的 Web 应用程序解耦。

通过这样做，

1. 您可以实施单点登录的替代方案：如果您有多个应用程序信任一个 STS。我的意思是，所有应用程序都使用一个用户名。
2. 您可以启用您的 Web 应用程序（客户端）访问属于用户和不属于 Web 应用程序（客户端）的资源。
3. 您可以将身份验证过程委托给您信任的第三方，而不必担心用户真实性验证。