OAuth 2.0 PKCE扩展场景下client_secret要求的技术问询

问题1：无论是否使用PKCE，强制token端点需client_secret是否违背行业惯例？ #

行业里并没有绝对统一的硬性惯例，从你提到的案例就能看出来：Spotify在PKCE场景下不要求client_secret，而Google则要求。这说明不同服务商是根据自身业务场景和安全考量制定规则的。

如果强制所有客户端（包括公开客户端）在使用PKCE时都提供client_secret，不算违背惯例，但要注意：公开客户端（SPA、移动应用等）本身无法安全存储client_secret，要求它们提供secret本质上只是走个形式——开发者要么把secret硬编码在客户端（反而增加泄露风险），要么只能通过其他方式绕开，反而可能带来不必要的麻烦。

你提到的“提升一致性、减少文档与代码复杂度”确实是合理考量，但也要权衡公开客户端开发者的实际体验。

问题2：若取消公开客户端的client_secret要求，PKCE流程是否仍需额外认证？能否仅依赖已注册的redirect_uris与PKCE实现安全？ #

对于公开客户端来说，取消client_secret要求后，仅依赖已注册的redirect_uri + PKCE就足够实现安全，不需要额外认证。原因如下：

• PKCE的核心作用是防止授权码拦截攻击：通过code_verifier和code_challenge的配对验证，确保只有发起授权请求的客户端才能换取令牌，即使授权码被拦截，攻击者也无法生成有效的code_verifier。
• 已注册的redirect_uri可以限制令牌只能回调到预先审核过的地址，避免恶意站点获取授权码。

另外要明确：PKCE本身就不是客户端认证的替代方案，它是针对公开客户端无法安全存储secret的场景补充的安全机制。对于公开客户端，本来就不适合用client_secret做认证，所以去掉secret要求，配合PKCE和redirect_uri校验，完全符合OAuth 2.0的安全规范。

额外建议 #

从安全和场景适配的角度，更合理的做法是区分客户端类型处理：

• 机密客户端：使用PKCE + client_secret认证，双重保障提升安全性，符合这类客户端能安全存储secret的特性。
• 公开客户端：使用PKCE + 无client_secret，仅依赖redirect_uri校验和PKCE验证，既贴合它们的技术限制，又能保证安全。

虽然统一规则能减少复杂度，但分场景处理更能兼顾安全和开发者体验，也更贴合行业主流的实践思路。

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