oauth-2.0 - 为什么在 native 应用程序中使用 PKCE 保护授权代码？之后是什么保护访问 token ？

Question

“授权码授予在本地应用程序上实现时存在一些安全问题。例如，恶意攻击者可以拦截授权服务器返回的授权码并将其交换为访问 token (可能还有刷新 token )。”引用:Auth0

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

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

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

[OAuth2 新手]

Answer 1

在没有反向 channel 的情况下，这里额外的 PKCE 保护有什么意义，以及两步过程(获取身份验证 token ，然后是访问 token )的意义是什么。

PKCE 保护的是前 channel 授权码响应。这里的前置 channel 是指用户代理(浏览器)的使用。

当您的应用程序在机器(例如:手机、台式机或 PC)上运行时，无法保护嵌入式 secret 。恶意方可以反编译源代码并提取嵌入式密码。因此，OAuth token 请求无法密码保护。

除此之外，任何恶意方都可以拦截用户代理(想想浏览器扩展)。因此，授权响应没有 native 保护。

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

1. 在应用程序中生成一个 secret (在内存中很难在运行时提取)
2. 对其进行哈希处理并将其包含在前端 channel (基于浏览器)授权请求中
3. 授权服务器会将哈希值与授权响应中发送的授权码相关联
4. 在 token 请求中包含 secret ，以便授权服务器可以验证

现在，即使恶意方拦截授权请求， secret 也会被散列。所以他们不能请求 token 。! secret 在内存中，因此难以提取。!

token 请求发生在反向 channel 中。它独立于浏览器(对授权服务器的直接 http 调用)。与基于浏览器的连接相比，它受到保护。

希望现在很清楚

额外信息 - token 请求可以包括客户端 ID 和客户端密码。包括客户 secret 使事情更加安全。但正如我所强调的， native 应用程序(PC、移动类应用程序)不能嵌入 secret 。因此 PKCE 添加了一个额外的安全层。!