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

Question

想象一下这次攻击

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

参考这张图： 流程：

问题

1. 是什么阻止了攻击者拦截对授权服务器的第一次调用？这就是为了让授权码 + PKCE 比隐式流更安全。

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

Answer 1

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

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

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

另请参阅：PKCE 实际上保护的是什么？

Answer 2

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

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

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