Oauth 2.0 在使用PKCE的OAuth 2.0授权代码流中，是什么阻止在第一次调用auth服务器时拦截代码质询？

想象一下这次袭击

攻击者截获对授权服务器的第一个调用，然后他们将面临代码挑战。（图中的步骤1）

攻击者现在使用授权代码拦截来自授权服务器的响应。（图中的步骤2）

然后，攻击者可以发布授权代码和代码验证器以获取访问令牌。（步骤3）

请参阅此图： 流量：

问题

是什么阻止攻击者拦截对授权服务器的第一次调用？这意味着授权代码+PKCE比隐式流更安全

也许拦截调用并不重要，因为代码质询是散列的，因此攻击者没有第二次调用所需的代码验证器。但是如果代码质询没有被散列呢

---

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

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

---

PKCE通过在身份验证请求中包含code_质询来解决此问题，该质询是代码验证器的散列。然后，它需要令牌交换调用中的实际验证器。恶意客户端没有验证器，因此无法对自身进行身份验证，因此无法将代码交换为令牌。

PKCE旨在解决访问令牌/授权代码从URL泄漏的威胁，与拦截SSL通信的攻击者相比，这是相对可能的：

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

这就是说，它建议代码质询是代码验证器的SHA256散列，因此即使攻击者拦截代码质询，他们也无法在无法反转SHA256的情况下完成令牌交换

---

另请参见：

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