@catanman 在 SPA 中围绕 PKCE 的技术考虑方面提出了很好的观点，但就在最近，IETF Oauth 工作组发布了一份最佳当前实践文档（2018 年 12 月 28 日），指出：

注意：虽然到目前为止 PKCE 被推荐作为保护本机应用程序的机制，但该建议适用于所有类型的 OAuth 客户端，包括 Web 应用程序。

虽然所有其他答案都是正确的，但最新的OAuth 2.0 for Browser-Based Apps Best Practices Doc（2019 年 1 月 29 日）指出（强调我的）：

4. 概述

对于在基于浏览器的应用程序中授权用户，
当前的最佳做法是

o 使用带有 PKCE 扩展的 OAuth 2.0 授权代码流

...

也

7.1。从基于浏览器的应用程序发起授权请求

基于浏览器的公共应用程序必须为 OAuth 实现代码
交换证明密钥 (PKCE [RFC7636])扩展，并且授权
服务器必须支持此类客户端的 PKCE。

PKCE 扩展通过为授权服务器提供一种方法来验证交换授权代码的同一客户端实例与启动流程的客户端实例相同，从而防止恶意客户端拦截授权代码并交换访问令牌的攻击.

我认为有一些小好处值得作为纵深防御，即使是基于浏览器的应用程序也是如此。

SPA 不会从 PKCE 中受益。PKCE 解决的问题与您描述的问题不同。

首先，对于SPA，当前的最佳实践仍然是使用隐式流，而不是授权码流。对于隐式流，访问令牌包含在重定向 URI的哈希片段 (#)中，而不是包含在查询组件 (?) 中。由于浏览器在发出请求时从不包含 URI 的哈希片段部分，因此令牌不会出现在浏览器历史记录、网络日志中......

谈到本机应用程序时，rfc8252 第 6节说明如下：

公共本机应用程序客户端必须实现代码交换的证明密钥 (PKCE RFC7636])

在旁注中，请注意 PKCE 要求适用于公共本地客户端。您可能想知道原生应用程序如何不公开。答案在第 8.4 节：

除非使用动态客户端注册 [RFC7591] 之类的机制来提供每个实例的机密，否则本机应用程序被归类为公共客户端

我不确定如何引用这些客户端，因为我从未见过任何地方提到过机密的本地客户端。也许非公共本机客户端可以工作:)

回答您的问题：那么为什么公共本机应用程序而不是 SPA 需要使用 PKCE 的授权代码流？

逻辑如下：

1. OAuth2 的主要目的之一是防止用户凭据暴露给客户端。
2. 要使本机应用程序满足此要求，用户不得在本机应用程序可以访问的任何地方输入凭据。因此，必须避免使用本机登录屏幕和 web 视图。
3. 解决方案是让原生应用程序启动一个外部用户代理（参见rfc8252 附录 B），用户将在其中向授权服务器进行身份验证并授权应用程序。本机应用程序无法访问外部用户代理，因此用户的凭据是安全的。
4. 但是，引入了 SPA 中不存在的新复杂情况：外部用户代理现在必须将授权服务器的响应传回本机应用程序？答案是应用间通信（参见第 5节和第 7 节）
5. 不幸的是，恶意的 3rd 方应用程序可以拦截多种类型的应用程序间通信！对于隐式流程，这意味着访问令牌可能会被恶意应用程序窃取，这将是一件非常糟糕的事情。这是原生应用不使用隐式流的主要原因之一。
6. 但是即使使用授权码流，恶意的第 3 方应用程序仍然可以拦截授权码，并使用它来获取访问令牌，因为没有客户端密码。因此对于公共原生应用程序使用授权代码流而不是隐式流似乎没有用。
7. 这就是 PKCE 的用武之地。PKCE 使得即使恶意应用程序拦截了授权代码，它也无法将其交换为访问令牌。这是通过要求请求访问令牌的实体证明它是首先请求授权代码的同一实体来实现的。

希望现在你明白为什么：

• SPA 根本不会从 PKCE 中受益，因为有了 SPA，一切都发生在浏览器中。PKCE 仅在存在应用程序间通信时才有用。
• 公共本机应用程序不应使用隐式流，因为应用程序间通信有时可能不安全。
• 公共原生应用应使用授权码流 + PKCE

这是一篇很好的博客文章，可以提供更多信息： https ://medium.com/@justinsecurity/mobile-apps-and-oauths-implicit-flow-68e72c6515a1