为什么在“隐式”流工作得这么好的情况下，OAuth2中还有一个“授权码”流呢？

Question

通过“隐式”流，在资源所有者（即用户）给予访问权之后，客户端（可能是浏览器）将获得一个访问令牌。

然而，对于“授权代码”流，客户端（通常是web服务器）仅在资源所有者（即用户）给予访问权之后才获得授权代码。使用该授权代码，客户机然后对API进行另一次调用，传递client_id和client_secret以及授权代码，以获得访问令牌。这里都有很好的描述。

这两个流具有完全相同的结果：访问令牌。不过，“隐性”流动要简单得多。

问题是：为什么要费心于“授权码”流量，当“隐性”流量接缝就好了？为什么不对WebServer也使用“隐式”呢？

Answer 1

TL；DR：这都是因为安全原因。

OAuth 2.0希望满足以下两个标准：

1. 您希望允许开发人员使用非HTTPS重定向URI，因为并非所有开发人员都有启用SSL的服务器，而且如果他们这样做了，它并不总是正确配置（非自签名、受信任的SSL证书、同步的服务器时钟……)。
2. 您不希望黑客能够通过拦截请求来窃取访问/刷新令牌。

详情如下：

由于安全原因,隐式流仅在浏览器环境中是可能的：

在隐式流中，访问令牌直接作为散列片段（而不是URL参数）传递。关于哈希片段的一个重要的事情是，一旦您跟踪包含哈希片段的链接，只有浏览器才知道该哈希片段。浏览器将把散列片段直接传递到目标网页（重定向URI/客户端的网页）。哈希片段具有以下属性：

null

这使得可以将访问令牌直接传递给客户端，而不会有被中间服务器截获的风险。这有一个警告，即只能在客户端使用，并且需要运行客户端的javascript来使用访问令牌。

隐式流还存在需要进一步的逻辑来解决/避免的安全问题，例如：

• 攻击者可以从不同网站/应用程序上的用户（假设他是其他网站/应用程序的所有者）获取访问令牌，将该令牌记录在他们的网站上，然后将其作为URL参数传递到您的网站上，从而假冒您网站上的用户。为了避免这种情况，您需要检查与访问令牌相关联的客户端ID（例如，对于Google，您可以使用tokeninfoendpoint），以确保令牌是用您自己的客户端ID（即通过您自己的应用程序）发出的，或者如果您正在使用IDToken，则检查签名（但这需要您的客户端机密）。
• 如果身份验证请求不是源自您自己的属性（称为会话固定攻击），为了避免这种情况，您将希望从您的网站生成一个随机哈希，将其保存在cookie中，并在身份验证请求的状态URL参数中传递相同的哈希，当用户返回时，您将使用cookie检查状态参数，并且它必须匹配。

在授权代码流中，不可能在URL参数中直接传递访问令牌，因为URL参数是HTTP请求的一部分，因此，如果您不使用加密连接(HTTPS)，允许所谓的中间人攻击，那么您的请求将通过的任何中间服务器/路由器（可能有数百个）都能够读取访问令牌。

理论上可以在URL参数中直接传递访问令牌，但身份验证服务器必须确保重定向URI使用带有TLS加密的HTTPS和“受信任的”SSL证书（通常来自非免费的证书颁发机构），以确保目标服务器是合法的，并且HTTP请求是完全加密的。让所有开发人员购买SSL证书并在他们的域上正确配置SSL将是一个巨大的痛苦，并且会极大地减缓采用SSL的速度。这就是为什么提供了一个中间的一次性使用的“授权代码”，只有合法的接收者才能够交换（因为您需要客户端机密），并且该代码对于通过未加密的事务拦截请求的潜在黑客将是无用的（因为他们不知道客户端机密）。

您还可以认为隐式流的安全性较低，存在潜在的攻击向量，比如在重定向时欺骗域--例如通过劫持客户端网站的IP地址。这就是为什么隐式流只授予访问令牌（它们应该有一个有限的时间使用）而从不刷新令牌（它们在时间上是无限的）的原因之一。为了解决这个问题，我建议您尽可能将您的网页放在启用HTTPS的服务器上。