OAuth2授权码流程中向终端用户返回令牌为何是不良实践？

核心风险：混淆客户端角色与令牌的设计意图 #

OAuth2的机密客户端（如Web服务器）和公开客户端（如浏览器、原生APP）有着完全不同的安全边界：

• 机密客户端能安全存储client_secret，可与授权服务器完成可信交互；
• 公开客户端（浏览器）没有安全的存储环境，令牌极易被XSS攻击、本地存储泄露等方式窃取。

把机密客户端获取的令牌返回给用户，等于将本应存放在可信服务器环境的凭证，转移到了完全不可控的前端环境，直接打破了OAuth2的安全模型。

针对你的两个误解逐一解释 #

1. 带PKCE的授权码流程 vs 机密客户端返回令牌的差异 #

带PKCE的授权码流程是为公开客户端量身设计的安全流程，从根源上解决了公开客户端的安全缺陷：

• PKCE流程中，浏览器拿到的令牌是授权服务器直接颁发给公开客户端的，全程不需要客户端持有client_secret，授权服务器通过code_verifier验证客户端身份，避免了授权码被拦截的风险；
• 公开客户端拿到的令牌本身适配不安全环境：比如access token生命周期极短，refresh token普遍采用“旋转式”设计（每次刷新都会生成新的凭证），就算旧凭证泄露，危害也有限；而机密客户端的refresh token是长期凭证，通常不会旋转，一旦泄露到前端，攻击者可无限刷新获取新的access token，直接接管用户权限；
• 最关键的是：PKCE流程中令牌的受众（audience）是公开客户端，而机密客户端的令牌受众是自身——把后者给用户，等于让用户拿着本该服务器使用的凭证调用API，API服务器会误认为调用方是机密客户端而非用户，直接导致权限校验逻辑混乱。

2. 和隐式流程的区别，以及你的场景为什么风险更大 #

隐式流程是直接通过URL片段返回access token，问题在于跳过授权码环节且无PKCE保护，易被拦截。但你的场景（机密客户端用授权码流程拿令牌后返回给用户）风险远大于隐式流程：

• 隐式流程通常仅返回access token（早期甚至不支持refresh token），而你的场景会把长期有效的refresh token也给到用户，泄露后的危害远超短期access token；
• 机密客户端的令牌是基于client_secret验证颁发的，一旦泄露，攻击者可冒充机密客户端操作；而隐式流程的令牌仅代表用户身份，无法冒充客户端；
• 你的场景完全混淆了客户端身份：API服务器收到请求时会判定调用方是机密客户端，而非用户，可能导致用户越权访问仅服务器能调用的API接口。

正确做法 #

机密客户端应自行持有access token和refresh token，前端需调用API时，由服务器作为代理：

1. 前端向自身Web服务器发起请求；
2. Web服务器使用持有的access token调用第三方API；
3. Web服务器将API结果返回给前端。

这种方式既保证了令牌的安全存储，也符合OAuth2的角色划分逻辑。

内容的提问来源于stack exchange，提问作者MyUsername112358