1

当前 OAuth2.0 安全主题的最佳实践草案在第 3.1.1 节中有以下内容：

“使用授权授予类型的客户端必须使用 PKCE [RFC7636] 以便（在授权服务器的帮助下）检测并防止将授权代码注入（重放）授权响应的尝试。......注意：虽然到目前为止 PKCE被推荐作为一种保护原生应用程序的机制，这个建议适用于所有类型的 OAuth 客户端，包括 Web 应用程序。”

  • “使用授权授权类型的客户端必须使用 PKCE ... 来检测和防止尝试将（回复）授权代码注入授权响应。”
    • PKCE 究竟如何帮助“检测”回复验证码的尝试？它的 RFC中没有任何内容表明它比OAuth2.0 RFC更好地处理检测，如果请求包含已使用的身份验证代码，则必须拒绝请求。
    • PKCE 究竟如何帮助“防止”对具有处理身份验证代码请求和重定向的后端的 Web 应用程序的授权代码重放攻击？我在假设身份验证代码请求和重定向都发生在 TLS 的情况下进行操作。有什么机会（以及它是如何工作的）可以重播身份验证代码？

需要注意的重要一点：

“...此建议适用于所有类型的 OAuth 客户端，...”捕获具有处理身份验证代码请求和访问令牌交换的后端组件的 Web 应用程序。因此，我们不是在谈论以前可能使用过隐式授权类型的 Web 应用程序；我们正在讨论可以使用授权授予类型的 Web 应用程序。

4

1 回答 1

0

以下是 RFC 7636 中的基本步骤。

  1. 客户端包含一个加密密钥，其中包含对 authz 端点的 authz 代码请求
  2. 身份验证服务器返回身份验证代码，其中包含在代码中加密或存储在身份验证服务器上的秘密
  3. 客户端将带有密钥的身份验证代码发送到令牌端点
  4. Authz 服务器验证秘密并以令牌响应

因此，只有当秘密被验证为之前为授权码发送的密钥时，授权服务器才会返回一个令牌。

正如您所建议的，这并不比拒绝多次使用同一授权代码的 OAuth 2.0 实现更好。但是，它的目的是防止使用与之前发送且与该秘密相关联的授权码或之前发送但没有正确秘密的授权码。

如果后端正在处理与 authz 服务器的通信并通过 TLS 进行，则不必担心 authz 代码攻击。但是授权码授权类型是基于重定向的流程。使用客户端凭据授予类型可能会更好地为您服务。这里的 Web 应用程序是指充当客户端的应用程序。

于 2019-10-10T21:37:11.133 回答