为什么要在本机应用程序中使用PKCE保护授权代码？此后如何保护访问令牌？

Question

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

如果我正确理解article，我们将竭尽全力保护使用PKCE在本机应用程序中的授权代码和访问代码的交换。

此处的前提是，攻击者“可以”实际拦截授权代码。因此，我们使用PKCE对其进行保护。但是什么阻止攻击者拦截访问令牌？

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

[OAuth2的新手]

Answer 1

在没有反向通道的情况下，这里提供额外的PKCE保护的意义是什么，两步过程的意义是什么（获取身份验证令牌，然后是访问令牌）。

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

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

此外，任何恶意方都可以拦截用户代理（请考虑使用浏览器扩展）。因此，对于授权响应没有本地保护。

为克服此问题，PKCE-RFC7636提供了一种将授权请求与令牌请求绑定的机制。

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

现在，即使恶意方拦截了授权请求，也会对机密进行哈希处理。因此，他们无法请求令牌。秘密是内存中的东西，很难提取。！

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

希望现在很清楚

其他信息-令牌请求可以包含客户端ID和客户端密码。包括客户机密可以使事情更加安全。但是正如我强调的那样，本机应用程序（个人计算机，移动应用程序）不能具有嵌入式机密。因此PKCE添加了额外的安全层。

Answer 2

访问令牌是短暂的。因此，如果访问令牌碰巧用在不正确的人身上，则他们将长时间无法使用它。但是，如果授权代码使用不当，则可以在更长的时间内使用它来获取访问令牌/刷新令牌。请注意，此访问令牌不是用于应用程序的受保护资源，而是用于用户的受保护资源。因此，应用程序应尽力保护自己，以防止授权代码落入错误的人手中。

对于PKCE，authorization code仅可与code_challenge和code_verifier（article）一起使用，因此仅使用authorization_code攻击者就无法获得{{1} }代表用户，因为他不处理access token

编辑：-授权流程的不安全性在于您无法保护移动设备中的code_verifier和client id。因此，攻击者可以简单地窃取您应用程序的client secret和client id。但是，未经用户同意，他不能仅以此访问用户的受保护资源。 secret仅在用户同意的情况下发布。因此，如果该代码落到了攻击者手中，攻击者将拥有所有参数来使用这些参数来获取authorization code和access_token并在用户不知情的情况下访问用户受保护的资源。 PKCE试图防止此类攻击。