带服务端的React客户端应用应选哪种OAuth2授权流程？

结合你的场景（拥有React客户端+自有服务端的Todo类应用），直接结论是放弃Implicit Flow，选择带PKCE的Authorization Code流程，原因如下：

1. Implicit Flow的核心问题 #

• 安全性不足：Implicit Flow会直接在前端返回access_token，令牌暴露在浏览器环境中，容易被XSS攻击窃取，且无法安全存储refresh_token（前端存储敏感信息本身存在风险）。
• 已被行业标准淘汰：OAuth 2.1规范已正式废弃Implicit Flow，即便针对纯客户端应用，现在也不推荐使用该流程。Google的相关推荐属于旧版实践，不符合当前安全最佳实践方向。

2. 带PKCE的Authorization Code流程的适配性与优势 #

• 适配多端架构：你的应用有自有服务端，正好匹配该流程的核心逻辑：前端先获取授权码（code），再将授权码传给服务端，由服务端向Google发起令牌交换请求，最终access_token和refresh_token只会留在服务端（或通过HttpOnly Cookie安全传递），彻底避免前端暴露敏感令牌的风险。
• 支持令牌静默刷新：服务端持有refresh_token后，可在access_token过期时自动完成令牌刷新，无需用户重新登录，大幅提升Todo应用的使用体验。
• 符合行业主流方向：Aaron Parecki的推荐完全契合当前OAuth生态的最佳实践，无论针对有后端的应用还是纯客户端应用，带PKCE的Authorization Code流程都是首选方案。

补充：关于纯客户端应用的实例 #

纯客户端应用指无自有后端API的单页应用，比如仅依赖第三方API完成功能的纯前端工具（如基于GitHub API的代码片段展示工具），但即便这类应用，现在也推荐使用带PKCE的Authorization Code流程，而非Implicit Flow。

内容的提问来源于stack exchange，提问作者Minh Nghĩa