在常规 Web 应用程序中使用 PKCE 流程，无需客户端凭据

Question

一些 OAuth 2.0 提供商（包括 Spotify 和 GitLab）既支持具有客户端凭据的常规 OAuth 2.0 授权代码授予类型（机密客户端），也支持使用 PKCE 且不具有客户端凭据的授权代码授予类型（公共客户端）。他们也不允许您将其限制为单一方法。

如果是这样，是否有理由使用带有客户端凭据的常规方法而不是仅使用 PKCE？

机密客户端的一大优点是您不能仅使用其客户端 ID 来模拟它，但在这种情况下，如果您将

code_challenge

传递到授权端点，则提供商不需要客户端凭据。

Answer 1

在 OAuth 安全 Web 应用程序中实现代码流有两种主要方法，并且端到端解决方案不仅仅是您提到的字段级详细信息。

仅前端流程

这些仅在 JavaScript 中实现其流程，并使用 PKCE，无需客户端密钥。这是一个相对简单的解决方案。

稍后更深层的行为是，您可能最终会在本地存储中存储刷新令牌，以便使多选项卡浏览可靠地工作。在现实世界的应用程序中不推荐这样做。

前端流程的后端

这些遵循 OAuth 2.1 建议，并使用 PKCE 和客户端凭据。在这种情况下，当浏览器调用 BFF 时，例如，如果恶意授权响应被注入到浏览器中，PKCE 仍然提供一些额外的保护。同样，客户端密钥可防止恶意浏览器代码调用令牌端点。

更深层的行为是，BFF 倾向于将令牌完全排除在浏览器之外，并使用仅 HTTP 的 cookie 层。这样做可以限制跨站点脚本攻击的影响。然而，它需要更复杂的流程。