在使用 PKCE 的 OAuth 2.0 授权代码流中，是什么阻止了在第一次调用身份验证服务器时拦截代码质询？答案

【问题标题】：In the OAuth 2.0 Authorization Code Flow with PKCE what prevents intercepting the code challenge on the first call to the auth server?在使用 PKCE 的 OAuth 2.0 授权代码流中，是什么阻止了在第一次调用身份验证服务器时拦截代码质询？
【发布时间】：2020-05-03 09:06:39
【问题描述】：

想象一下这次攻击

攻击者拦截了对授权服务器的第一次调用，然后他们进行了代码挑战。（图中的第 1 步）
攻击者现在拦截来自授权服务器的带有授权码的响应。（图中的第 2 步）
然后攻击者可以通过 POST 授权码和验证码获取访问令牌。（第 3 步）

参考这张图：流量：

问题

是什么阻止了攻击者拦截对授权服务器的第一次调用？这就是为了让授权码 + PKCE 比隐式流更安全。
也许调用是否被拦截并不重要，因为代码质询是经过哈希处理的，因此攻击者没有第二次调用所需的代码验证器。但是如果代码挑战没有经过哈希处理呢？

【问题讨论】：

标签： oauth-2.0 openid-connect pkce

【解决方案1】：

PKCE 旨在解决访问令牌/授权代码从 URL 泄露的威胁，与攻击者拦截 SSL 流量相比，这种威胁相对比较容易：

网址在地址栏中可见
网址保存在浏览器历史记录中
在本机平台上，可以注册多个应用程序以使用相同的自定义 URI 方案

也就是说，它建议代码质询是代码验证器的 SHA256 哈希，因此即使攻击者拦截代码质询，他们也无法完成令牌交换而无法反转 SHA256。

另见：What is PKCE actually protecting?

【讨论】：

【解决方案2】：

PKCE 旨在确保请求用户进行身份验证的客户端与将授权代码交换为访问令牌的客户端相同。

与授权服务器的所有通信都使用HTTPS，很难拦截。但是一些移动平台允许（恶意）应用程序将相同的 redirect_uri 注册为合法客户端。这意味着当授权服务器使用授权码重定向回客户端时，合法客户端和恶意客户端都会被调用。这允许恶意客户端将代码交换为访问令牌，因为没有进行客户端身份验证。

PKCE 通过在身份验证请求中包含 code_challenge 来解决这个问题，这是代码验证器的哈希。然后它需要令牌交换调用中的实际验证者。恶意客户端没有验证者，因此无法验证自己，因此无法将代码交换为令牌。

【讨论】：

因此，如果没有 PKCE，您只需使用相同的 redirect_uri 注册另一个恶意应用程序，当合法应用程序调用授权服务器请求授权代码时，您的恶意应用程序也会被调用？这听起来非常不安全，还是我在这里误解了什么？
不确定。问题是安装在您手机上的恶意应用程序可能会注册与您的银行应用程序相同的激活 URL（手机应用程序通常使用自定义方案来激活 URL）。在这种情况下，它们将在与您的银行应用程序相同的重定向 URL 上被激活，并且可以从 URL 中检索授权代码。