oauth - 我们真的需要 client_secret 来获取 PKCE 流程上的 access_token 吗？

Question

我正在构建 2 个应用程序；一个前端，一个后端。
后端将使用 Rails API + Doorkeeper Gem(oauth2 提供程序)构建，而前端将使用 React Native 构建。
目前，我正在使用“客户端凭据授予流程”，它目前工作正常。但是经过一段时间的研究，这个流程不应该在客户端应用程序中使用，因为它暴露了 client_secret如果有人反编译该应用程序。
我还阅读了“隐式授权流”，它只需要 client_id .但是这个流程现在看起来有点老了？
根据这个:https://auth0.com/docs/api-auth/which-oauth-flow-to-use#is-the-client-a-single-page-app-
建议使用“带有 PKCE 的授权代码授予”而不是“隐式授予流程”。我能够让它工作，但问题是它仍然需要 client_secret为了得到一个 access_token ，这是应该的吗？
这是我正在做的示例流程:

curl -X POST 'http://localhost:3000/oauth/authorize?client_id=xxxx&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&scope=public&code_challenge=testchallenge&code_challenge_method=plain'

这会给我以下回复:

{
    "status": "redirect",
    "redirect_uri": {
        "action": "show",
        "code": "8quZ-EAiKKG2EKnQiSYs3xeFRCgsIwcTbaWNdjnpyFg"
    }
}

然后我将使用上面的代码使用以下请求获取访问 token :

curl -i http://localhost:3000/oauth/token \
  -F grant_type="authorization_code" \
  -F client_id="xxxx" \
  -F client_secret="xxxx" \
  -F code="8quZ-EAiKKG2EKnQiSYs3xeFRCgsIwcTbaWNdjnpyFg" \
  -F redirect_uri="urn:ietf:wg:oauth:2.0:oob" \
  -F code_verifier="testchallenge"

现在问题来了，为了交换 code到 access_token我仍然需要 client_secret .如果两者都只公开我的 client_secret，它与“客户端凭据授予流程”有何不同？ ?
上面的命令将返回以下内容:

{
    "access_token": "nQoorBqLxQH4qFpmlx3mGG6Cd_TfX4d3L3gAGOTwrFs",
    "token_type": "Bearer",
    "expires_in": 7200,
    "scope": "public",
    "created_at": 1595517643
}

如果我不包括 client_secret这里的请求是响应:

{
    "error": "invalid_client",
    "error_description": "Client authentication failed due to unknown client, no client authentication included, or unsupported authentication method."
}

所以这里是我的问题:

我们真的需要client_secret获取 access_token在 PKCE 流程上？

如果只会暴露client_secret，为什么建议使用“PKCE Flow” ?

它与同样公开 client_secret 的“Client Credentials Grant Flow”有何不同？ ?

Doorkeeper PKCE 文档: https://github.com/doorkeeper-gem/doorkeeper/wiki/Using-PKCE-flow

Answer 1

带有 PKCE 的授权代码流是为 的设置而发明的。客户端无法安全地保护 secret .因此，当将授权代码流与 PKCE 一起使用时，您 不需要一个 secret 或更确切地说是客户的 secret 是没有意义的。
您所遇到的似乎是 门卫漏洞 (见 https://github.com/doorkeeper-gem/doorkeeper/issues/1089)。所以恐怕在他们修复它之前，您将不得不使用一些虚拟的客户端 secret 。
但是，只要 Doorkeeper 正确实现了 PKCE 流程的其余部分，这应该不是问题，因为此流程不依赖于任何静态客户端 secret ，而是使用您已经指出的动态创建的代码验证程序。
我不确定我是否正确理解您正在使用哪种客户端来处理登录。如果它是 SPA 或移动应用程序，您应该使用带有 PKCE 的授权代码流，但如果您正在实现一个“经典”的 Web 应用程序，其中登录在某些后端服务中处理，您应该使用客户端 key 使用正常的授权代码流作为可以信任后端来保护 secret 。
顺便说一下，我刚刚检查了我正在处理的一个项目中的代码，我在其中构建了一些 Angular SPA，它通过 Auth0 作为身份提供者进行身份验证。我在那里使用带有 PKCE 的授权代码流，我绝对不会向 Auth0 发送任何客户端 secret ，因为显然该流是按预期实现的。所以这真的必须是 Doorkeeper 的问题。
另一件事:我不知道您提供的请求是否只是示例，但不是使用普通方法将代码验证器转换为代码挑战，我宁愿使用安全方法，例如 S256，而不是 RFC 中推荐的你在你的问题中提到了。