如何使用 PKCE 保护 OIDC 授权代码流不被特权管理员拦截？

Question

我真的很难理解这个问题。我有一个假设的流程，其中包括 3 个实体：用户/浏览器、AuthServer、客户端/应用程序。此流程将授权代码流程与 PKCE 一起使用。步骤如下：

1. 用户点击登录
2. 客户端/应用程序生成代码质询和验证器。将用户重定向到 AuthServer
3. 用户按照重定向到 AuthServer，包括代码质询。 AuthServer 存储此信息以供以后验证。
4. Authserver 响应登录提示
5. 用户认证成功
6. Authserver 通过重定向到客户端将 Authcode 发送回用户浏览器
7. 用户浏览器发送AuthCode到客户端/应用程序
8. 客户端/应用程序将此代码与 AuthServer 交换 ID 令牌，它使用之前的验证器以及客户端密钥。
9. 客户端/应用程序向用户发送 ID 令牌并建立会话

现在针对攻击场景：假设用户是一家公司的员工，该公司使用 Web 代理，该 Web 代理会拦截并终止并存储其之间的所有 TLS 流量。特权管理员可以访问此代理并具有恶意意图 - 什么会阻止此管理员在步骤 6 中重放请求，并基本上劫持身份验证并窃取生成的令牌？我不知道 PKCE 在这里有什么帮助，因为在这种情况下这只是验证客户端，并且客户端仍然是正确的。

Answer 1

您是正确的，如果授权代码和验证程序被拦截，PKCE 本身并不能防止重播攻击，因为它假设客户端是值得信赖的，但代理管理员是否仍然需要拥有代码验证程序，我想知道如何得到了吗？

您可以应用多种缓解技术来解决您的问题。

• 使用单一的、短期的授权代码，这会显着降低重放攻击的有效性。即使恶意管理员能够捕获授权码，一旦使用也将失效。
• 使用

  Certificate Pinning

  的概念可以防止代理终止客户端/应用程序与AuthServer之间的TLS连接，从而阻止管理员拦截和读取授权代码或验证程序的能力
• 令牌绑定在这种情况下也很有帮助。它可以确保即使授权码或 ID 令牌被盗，攻击者也无法在另一台设备或另一会话中使用这些令牌。
• IP白名单和地理定位也常用于此类场景。一些授权服务器实施 IP 白名单或地理位置检查。如果第 6 步中请求的 IP 地址或地理位置与根据用户之前的行为所预期的不同，则该请求可能会被拒绝。
• 会话绑定是减轻此类风险的另一种方法。您可以将会话绑定到客户端/应用程序，以便从另一个位置重播的授权代码或令牌将触发异常检测系统，从而可能使会话无效。