为什么会出现一个＆QUOT;授权code＆QUOT;流入的OAuth2当＆QUOT;隐＆QUOT;流这么好？ [英] Why is there an "Authorization Code" flow in OAuth2 when "Implicit" flow works so well?

问题描述

使用的隐式流动的客户机（可能是一个浏览器）会得到一个访问令牌，资源所有者（即，用户）后，得到的访问。

With the "Implicit" flow the client (likely a browser) will get a access token, after the Resource Owner (i.e. the user) gave access.

然而随着授权code流，客户端（通常是网络服务器）不仅获取资源所有者（即，用户）后授权code送给访问。该项授权code客户端然后进行另一个调用API传球CLIENT_ID和授权code一起client_secret来获得访问令牌。 所有好这里描述。

With the "Authorization Code" flow however, the client (usually a web server) does only get an authorization code after the Resource Owner (i.e. the user) gave access. With that authorization code the client then makes another call to the API passing client_id and client_secret together with the authorization code to obtain the access token. All well described here.

两个流都具有完全相同的结果：一个访问令牌。然而，隐式流动要简单得多。

Both flows have the exact same result: an access token. However, the "Implicit" flow is much simpler.

问题：为什么要与授权code流，当隐流接缝何苦要被罚款？为什么不也在使用隐的Web服务器？

这既为供应商和客户更多的工作。

It's more work both for the provider and the client.

推荐答案

TL; DR：这是所有因安全原因

OAuth 2.0用户要满足这两个标准：

OAuth 2.0 wanted to meet these two criteria:

1. 您想允许开发人员使用非HTTPS重定向URI，因为不是所有的开发人员都启用SSL服务器，如果他们这样做并不总是正确配置（非自签署的，值得信赖的SSL证书，同步服务器时钟......）


2. 您不希望黑客能够通过拦截请求窃取访问/刷新令牌。

下面的详细信息：

隐含的流动是唯一可能在因安全原因在浏览器环境：

The implicit flow is only possible in a browser environment because of security reasons:

在隐流程访问令牌直接传递作为哈希代码（而不是作为一个URL参数）。有关哈希片段一个重要的事情是，一旦你按照包含哈希代码的链接，只有浏览器是知道的哈希片段。浏览器将直接将哈希代码到目标网页（重定向URI /客户端的网页）。哈希片段具有以下属性：

In the implicit flow the access token is passed directly as a hash fragment (not as a URL parameter). One important thing about hash fragment is that, once you follow a link containing a hash fragment, only the browser is aware of the hash fragment. Browsers will pass the hash fragment directly to the destination webpage (the redirect URI / the client's webpage). Hash fragment have the following properties:

• 它们不是HTTP请求，因此它们不能被服务器和的，因为它们不能由中介服务器/路由器（这是很重要的）被截取读取的一部分。

客户端 - -
• 他们仅在浏览器上存在。所以读取散列片段的唯一方法是使用在网页中运行的JavaScript

此使得能够直接传​​递访问令牌至客户端，而不它由一个中介服务器截获的风险。这仅仅是可能的客户端的警告，需要运行的JavaScript客户端使用的访问令牌。

This makes it possible to pass an Access Token directly to the client without the risk of it being intercepted by an intermediary server. This has the caveat of only being possible client side and needs javascript running client side to use the access token.

在授权code流量这是不可能的令牌直接在URL参数传递的访问，因为URL参数是HTTP请求的一部分，因此任何中介服务器/路由器由你的请求会通过（可能是数百个）可能是能够读取访问令牌，如果你不使用连接加密连接（HTTPS）允许了所谓的人在这方面的中间人攻击。

In the authorization code flow it is not possible to pass an access token directly in a URL parameter because URL parameters are part of the HTTP Request, therefore any intermediary server/routers by which your request would pass (could be hundreds) could be able to read the access token if you are not using en encrypted connection (HTTPS) allowing what's known as Man-in-the-middle attacks.

标记直接在URL参数传递访问可能在理论上是可能的，但权威性SEVER必须确保URI是使用HTTPS使用TLS加密重定向和可靠从证书颁发机构是SSL证书（一般不是免费的），以确保目标服务器是合法的，而且HTTP请求完全加密。其所有的开发人员购买SSL证书，并正确地配置自己的域的SSL将是一个巨大的痛苦，并会极大地缓慢通过了下来。这就是为什么中介一次性使用的授权，code的规定，只有合法的接收器将能够交换（因为你需要的客户端密钥），而code将是无用的潜在黑客拦截通过未加密的交易请求（因为他们不知道客户端密钥）。

Passing the access token directly in a URL param could in theory be possible but the auth sever would have to make sure the redirect URI is using HTTPS with TLS encryption and a 'trusted' SSL certificate (typically from a Certificate Authority that is not free) to be sure that the destination server is legitimate and that the HTTP request is fully encrypted. Having all developers purchase an SSL certificate and properly configure SSL on their domain would be a huge pain and would slow adoption down tremendously. This is why an intermediary one-time-use "authorization code" is provided that only the legitimate receiver will be able to exchange (because you need the client secret) and that the code will be useless to potential hackers intercepting the requests over unencrypted transactions (because they don't know the client secret).

您也可以争辩说，隐流的安全性较低，有喜欢在重定向欺骗域潜在的攻击媒介 - 通过劫持客户的网站的IP地址的例子。这就是为什么隐流只允许访问令牌（这是应该有一个有限的时间用），从不刷新令牌（这是在时间无限制）的原因之一。为了解决这个问题，我建议你举办一个启用HTTPS的服务器上的网页只要有可能。

You could also argue that the implicit flow is less secure, there are potential attack vectors like spoofing the domain upon redirect - for example by hijacking the IP address of the client's website. This is one of the reasons why the implicit flow only grants access tokens (which are supposed to have a limited time use) and never refresh tokens (which are unlimited in time). To remedy this issue, I advise you to host your webpages on an HTTPS-enabled server whenever possible.

这篇关于为什么会出现一个＆QUOT;授权code＆QUOT;流入的OAuth2当＆QUOT;隐＆QUOT;流这么好？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！