为什么在原生应用中使用 PKCE 保护授权码？此后什么保护访问令牌？

Question

“在本机应用程序上实施时，授权代码授予存在一些安全问题。例如，恶意攻击者可以拦截授权服务器返回的授权代码并将其交换为访问令牌（可能还有刷新令牌）。” 参考：Auth0

如果我正确理解了这篇文章，我们会竭尽全力保护使用 PKCE 的本机应用程序中的授权代码和访问代码的交换。

这里的前提是攻击者“可以”实际拦截授权码。所以我们使用 PKCE 来保护它。但是是什么阻止了攻击者拦截访问令牌？

编辑：请忽略以下内容，因为它似乎因模棱两可而使其他读者感到困惑。“这里额外的 PKCE 保护有什么意义，当没有反向通道时，两步过程（获取身份验证令牌，然后获取访问令牌）有什么意义。”

[OAuth2 新手]

Answer 1

此处额外 PKCE 保护的意义何在，以及当没有反向通道时两步过程（获取身份验证令牌，然后获取访问令牌）的意义何在。

PKCE 保护的是前端通道授权码响应。这里的前端通道是指用户代理（浏览器）的使用。

当您的应用程序在机器上运行时（例如：手机、台式机或个人电脑），无法保护嵌入式机密。恶意方可以反编译源代码并提取嵌入的密码。因此，OAuth 令牌请求不能受密码保护。

除此之外，用户代理可以被任何恶意方拦截（想想浏览器扩展）。因此，没有对授权响应的本地保护。

为了克服这个问题，PKCE - RFC7636提供了一种将授权请求与令牌请求绑定的机制。以非常抽象的方式，

1. 在应用程序中生成一个秘密（在内存中很难在运行时提取）
2. 散列它并将其包含在前端通道（基于浏览器）授权请求中
3. 授权服务器会将哈希值与授权响应中发送的授权码相关联
4. 在令牌请求中包含秘密，以便授权服务器可以验证

现在，即使恶意方拦截授权请求，秘密也会被散列。所以他们不能请求令牌。！秘密是在内存中，这使得它难以提取。！

令牌请求发生在反向通道中。它独立于浏览器（直接 http 调用授权服务器）。与基于浏览器的连接相比，这是受保护的。

希望现在清楚了

额外信息 - 令牌请求可以包括客户端 ID 和客户端机密。包括客户端机密使事情更安全。但正如我所强调的，本机应用程序（个人电脑、移动应用程序）不能嵌入秘密。因此 PKCE 添加了一个额外的安全层。！