OAuth 2.0:好处和用例——为什么? [英] OAuth 2.0: Benefits and use cases — why?
问题描述
谁能解释一下 OAuth2 的优点以及我们为什么要实施它?我这么问是因为我对此有点困惑——这是我目前的想法:
Could anyone explain what's good about OAuth2 and why we should implement it? I ask because I'm a bit confused about it — here's my current thoughts:
OAuth1(更准确地说是 HMAC)请求看起来合乎逻辑、易于理解、易于开发并且非常非常安全.
OAuth1 (more precisely HMAC) requests seem logical, easy to understand, easy to develop and really, really secure.
相反，OAuth2 带来了授权请求、访问令牌和刷新令牌，您必须在会话开始时发出 3 个请求才能获取所需的数据.即便如此，当令牌过期时，您的一个请求最终会失败.
OAuth2, instead, brings authorization requests, access tokens and refresh tokens, and you have to make 3 requests at the very start of a session to get the data you're after. And even then, one of your requests will eventually end up failing when the token expires.
要获得另一个访问令牌，您可以使用与访问令牌同时传递的刷新令牌.从安全的角度来看，这是否会使访问令牌变得无用?
And to get another access token, you use a refresh token that was passed at the same time as the access token. Does that make the access token futile from a security point of view?
此外，正如/r/netsec 最近表明的那样，SSL 并非完全安全，因此将所有内容都放到 TLS/SSL 而不是安全的 HMAC 上的做法让我感到困惑.
Plus, as /r/netsec have showed recently, SSL isn't all entirely secure, so the push to get everything onto TLS/SSL instead of a secure HMAC confuses me.
OAuth 认为它不是 100% 安全，而是让它发布和完成.从提供商的角度来看，这听起来并不完全有希望.当草案提到 6 种不同的流程时，我可以看到它试图达到什么目的，但在我的脑海中并没有完全吻合.
OAuth are arguing that it's not about 100% safety, but getting it published and finished. That doesn't exactly sound promising from a provider's point of view. I can see what the draft is trying to achieve when it mentions the 6 different flows, but it's just not fitting together in my head.
我认为这可能更多是我在努力理解它的好处和推理而不是真正不喜欢它，所以这可能有点无端攻击，如果这看起来像是咆哮，我很抱歉.
I think it might be more my struggling to understand it's benefits and reasoning than actually disliking it, so this may be a bit of an unwarranted attack, and sorry if this could seem like a rant.
推荐答案
背景:我为 OAuth 1.0a 和 2.0 编写了客户端和服务器堆栈.
Background: I've written client and server stacks for OAuth 1.0a and 2.0.
OAuth 1.0a 和2.0 支持双腿认证，服务器保证用户的身份，以及三腿认证，服务器由用户身份的内容提供者保证.三足认证是授权请求和访问令牌发挥作用的地方，重要的是要注意 OAuth 1 也有这些.
Both OAuth 1.0a & 2.0 support two-legged authentication, where a server is assured of a user's identity, and three-legged authentication, where a server is assured by a content provider of the user's identity. Three-legged authentication is where authorization requests and access tokens come into play, and it's important to note that OAuth 1 has those, too.
OAuth 规范的一个要点是让内容提供商(例如 Facebook、Twitter 等)确保服务器(例如希望代表客户端与内容提供者交谈)客户端有一些身份.三足身份验证提供的功能是无需客户端或服务器知道该身份的详细信息(例如用户名和密码)即可做到这一点.
A main point of the OAuth specs is for a content provider (e.g. Facebook, Twitter, etc.) to assure a server (e.g. a Web app that wishes to talk to the content provider on behalf of the client) that the client has some identity. What three-legged authentication offers is the ability to do that without the client or server ever needing to know the details of that identity (e.g. username and password).
没有 (?) 深入了解 OAuth 的细节:
Without (?) getting too deep into the details of OAuth:
- 客户端向服务器提交授权请求，服务器验证客户端是其服务的合法客户端.
- 服务器将客户端重定向到内容提供者以请求访问其资源.
- 内容提供者验证用户的身份，并经常请求他们授予访问资源的权限.
- 内容提供者将客户端重定向回服务器，通知它成功或失败.此请求包含成功时的授权代码.
- 服务器向内容提供者发出带外请求并交换访问令牌的授权码.
服务器现在可以通过传递访问令牌来代表用户向内容提供者发出请求.
The server can now make requests to the content provider on behalf of the user by passing the access token.
每个交换(客户端->服务器、服务器->内容提供者)都包括对共享机密的验证，但由于 OAuth 1 可以在未加密的连接上运行，因此每次验证都无法通过网络传递机密.
Each exchange (client->server, server->content provider) includes validation of a shared secret, but since OAuth 1 can run over an unencrypted connection, each validation cannot pass the secret over the wire.
正如您所指出的，HMAC 已经完成了.客户端使用它与服务器共享的秘密来签署其授权请求的参数.服务器接受这些参数，用客户端的密钥对它们本身进行签名，并能够查看它是否是合法客户端(在上面的第 1 步中).
That's done, as you've noted, with HMAC. The client uses the secret it shares with the server to sign the arguments for its authorization request. The server takes the arguments, signs them itself with the client's key, and is able to see whether it's a legitimate client (in step 1 above).
这个签名要求客户端和服务器就参数的顺序达成一致(所以他们签署的是完全相同的字符串)，关于 OAuth 1 的主要抱怨之一是它需要服务器和客户端排序和签名相同.这是一个繁琐的代码，要么它是正确的，要么你在几乎没有帮助的情况下获得 401 Unauthorized.这增加了编写客户端的障碍.
This signature requires both the client and the server to agree on the order of the arguments (so they're signing exactly the same string), and one of the main complaints about OAuth 1 is that it requires both the server and clients to sort and sign identically. This is fiddly code and either it's right or you get 401 Unauthorized with little help. This increases the barrier to writing a client.
通过要求授权请求通过 SSL 运行，OAuth 2.0 完全不需要参数排序和签名.客户端将其秘密传递给服务器，服务器直接对其进行验证.
By requiring the authorization request to run over SSL, OAuth 2.0 removes the need for argument sorting and signing altogether. The client passes its secret to the server, which validates it directly.
同样的要求存在于服务器->内容提供者连接中，因为这是 SSL，它消除了编写访问 OAuth 服务的服务器的一个障碍.
The same requirements are present in the server->content provider connection, and since that's SSL that removes one barrier to writing a server that accesses OAuth services.
这让上面的步骤 1、2 和 5 中的事情变得容易多了.
That makes things a lot easier in steps 1, 2, and 5 above.
所以此时我们的服务器有一个永久访问令牌，它是用户的用户名/密码等价物.它可以通过将访问令牌作为请求的一部分(作为查询参数、HTTP 标头或 POST 表单数据)传递来代表用户向内容提供者发出请求.
So at this point our server has a permanent access token which is a username/password equivalent for the user. It can make requests to the content provider on behalf of the user by passing that access token as part of the request (as a query argument, HTTP header, or POST form data).
如果仅通过 SSL 访问内容服务，我们就完成了.如果它可以通过纯 HTTP 获得，我们希望以某种方式保护该永久访问令牌.任何嗅探连接的人都可以永远访问用户的内容.
If the content service is accessed only over SSL, we're done. If it's available via plain HTTP, we'd like to protect that permanent access token in some way. Anyone sniffing the connection would be able to get access to the user's content forever.
在 OAuth 2 中解决的方法是使用刷新令牌.刷新令牌成为等效的永久密码，并且它只通过 SSL 传输.当服务器需要访问内容服务时，它会将刷新令牌交换为短期访问令牌.这样，所有可嗅探的 HTTP 访问都是使用将过期的令牌进行的.Google 对其 OAuth 2 API 使用了 5 分钟的过期时间.
The way that's solved in OAuth 2 is with a refresh token. The refresh token becomes the permanent password equivalent, and it's only ever transmitted over SSL. When the server needs access to the content service, it exchanges the refresh token for a short-lived access token. That way all sniffable HTTP accesses are made with a token that will expire. Google is using a 5 minute expiration on their OAuth 2 APIs.
因此，除了刷新令牌之外，OAuth 2 还简化了客户端、服务器和内容提供者之间的所有通信.刷新令牌仅用于在未加密访问内容时提供安全性.
So aside from the refresh tokens, OAuth 2 simplifies all the communications between the client, server, and content provider. And the refresh tokens only exist to provide security when content is being accessed unencrypted.
不过，有时服务器只需要控制对自己内容的访问.两条腿认证允许客户端直接向服务器认证用户.
Sometimes, though, a server just needs to control access to its own content. Two-legged authentication allows the client to authenticate the user directly with the server.
OAuth 2 标准化了一些广泛使用的 OAuth 1 扩展.我最了解的一个是 Twitter 介绍的 xAuth.您可以在 OAuth 2 中将其视为 Resource Owner Password凭据.
OAuth 2 standardizes some extensions to OAuth 1 that were in wide use. The one I know best was introduced by Twitter as xAuth. You can see it in OAuth 2 as Resource Owner Password Credentials.
本质上，如果您可以信任具有用户凭据(用户名和密码)的客户端，他们可以直接与内容提供者交换这些凭据以获取访问令牌.这使得 OAuth 在移动应用上更有用——通过三足身份验证，您必须嵌入 HTTP 视图才能处理与内容服务器的授权过程.
Essentially, if you can trust the client with the user's credentials (username and password), they can exchange those directly with the content provider for an access token. This makes OAuth much more useful on mobile apps--with three-legged authentication, you have to embed an HTTP view in order to handle the authorization process with the content server.
对于 OAuth 1，这不是官方标准的一部分，需要与所有其他请求相同的签名程序.
With OAuth 1, this was not part of the official standard, and required the same signing procedure as all the other requests.
我刚刚使用资源所有者密码凭证实现了 OAuth 2 的服务器端，从客户端的角度来看，获取访问令牌变得很简单:从服务器请求访问令牌，将客户端 ID/秘密作为 HTTP 授权传递标题和用户的登录名/密码作为表单数据.
I just implemented the server side of OAuth 2 with Resource Owner Password Credentials, and from a client's perspective, getting the access token has become simple: request an access token from the server, passing the client id/secret as an HTTP Authorization header and the user's login/password as form data.
因此，从实施者的角度来看，我在 OAuth 2 中看到的主要优势在于降低了复杂性.它不需要请求签名程序，这并不完全困难，但肯定很繁琐.它大大减少了充当服务客户端所需的工作，而这正是(在现代移动世界中)您最希望最大程度减少痛苦的地方.服务器->内容提供商端的复杂性降低，使其在数据中心更具可扩展性.
So from an implementor's perspective, the main advantages I see in OAuth 2 are in reduced complexity. It doesn't require the request signing procedure, which is not exactly difficult but is certainly fiddly. It greatly reduces the work required to act as a client of a service, which is where (in the modern, mobile world) you most want to minimize pain. The reduced complexity on the server->content provider end makes it more scalable in the datacenter.
并且它将 OAuth 1.0a 的一些扩展(如 xAuth)编入标准，这些扩展现在被广泛使用.
And it codifies into the standard some extensions to OAuth 1.0a (like xAuth) that are now in wide use.
这篇关于OAuth 2.0:好处和用例——为什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
