authentication - 当 "Authorization Code"流运行良好时，为什么 OAuth2 中存在 "Implicit"流？

Question

通过“隐式”流程，在资源所有者(即用户)授予访问权限后，客户端(可能是浏览器)将获得访问 token 。

然而，使用“授权码”流程，客户端(通常是 Web 服务器)只会在资源所有者(即用户)授予访问权限后才获得授权码。使用该授权代码，客户端然后再次调用 API，传递 client_id 和 client_secret 以及授权代码以获取访问 token 。 All well described here .

两个流程都具有完全相同的结果:访问 token 。但是，“隐式”流程要简单得多。

问题:当“隐式”流接缝没问题时，为什么要打扰“授权码”流？为什么不对网络服务器也使用“隐式”？

这对提供者和客户来说都是更多的工作。

Answer 1

tl;博士:这都是出于安全原因。

OAuth 2.0 想要满足这两个标准:

您希望允许开发人员使用非 HTTPS 重定向 URI，因为并非所有开发人员都有启用 SSL 的服务器，而且如果他们这样做，则配置并不总是正确(非自签名、受信任的 SSL 证书、同步服务器时钟......)。

您不希望黑客能够通过拦截请求来窃取访问/刷新 token 。

详情如下:

由于安全原因，隐式流只能在浏览器环境中使用:

在 隐式流量访问 token 直接作为哈希片段传递(而不是作为 URL 参数)。关于散列片段的一件重要事情是，一旦您点击包含散列片段的链接，只有浏览器知道散列片段。浏览器会将哈希片段直接传递到目标网页(重定向 URI/客户端的网页)。哈希片段具有以下属性:

它们不是 HTTP 请求的一部分，因此它们不能被服务器读取，因此它们不能被中间服务器/路由器拦截(这很重要)。

它们只存在于浏览器 - 客户端 - 所以读取哈希片段的唯一方法是使用在页面上运行的 JavaScript。

这使得可以将访问 token 直接传递给客户端，而没有被中间服务器拦截的风险。这有一个警告，即只能是可能的客户端，并且需要运行客户端的 javascript 才能使用访问 token 。

隐式流也有安全问题，需要进一步的逻辑来解决/避免，例如:

攻击者可以从不同网站/应用程序的用户那里获取访​​问 token (假设他是另一个网站/应用程序的所有者)，在他们的网站上记录 token ，然后将其作为 URL 参数传递到您的网站上因此在您的网站上冒充用户。为避免这种情况，您需要检查与访问 token 关联的客户端 ID(例如，对于 Google，您可以使用 tokeninfo 端点)以确保 token 是使用您自己的客户端 ID(即由您自己的应用程序)颁发的或检查签名如果您使用的是 IDToken(但这需要您的客户端密码)。

如果身份验证请求不是来自您自己的属性(property)(称为 session 固定攻击)，为避免这种情况，您需要从您的网站生成一个随机哈希，将其保存在 cookie 中并在状态 URL 参数中传递相同的哈希auth 请求，当用户回来时，您用 cookie 检查状态参数，它必须匹配。

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

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

您还可以争辩说，隐式流不太安全，存在潜在的攻击媒介，例如在重定向时欺骗域 - 例如通过劫持客户端网站的 IP 地址。这就是为什么隐式流只授予访问 token (应该有有限的使用时间)而从不刷新 token (时间不受限制)的原因之一。为了解决这个问题，我建议您尽可能在支持 HTTPS 的服务器上托管您的网页。