支持双授权模式的OAuth2提供商：为何选用客户端凭证而非仅PKCE？

有些OAuth 2.0服务提供商（比如Spotify、GitLab）同时支持两种授权码授予类型：一种是针对机密客户端、需要客户端凭证的常规模式，另一种是针对公开客户端、无需客户端凭证但使用PKCE的模式，而且无法限制只能用其中一种。在这种同时支持两种方式的场景下，有没有理由选择用客户端凭证的模式，而不是只依赖PKCE？

机密客户端的核心优势之一是仅靠客户端ID无法冒充该客户端，但在这类场景里，如果向授权端点传递code_challenge，服务提供商就不会要求提供客户端凭证。

• 更强的身份校验层级：PKCE主要用来防止授权码被拦截后的重放攻击，但客户端凭证是从客户端身份层面做校验。就算PKCE的code_challenge验证通过，服务端还能通过客户端凭证二次确认客户端合法性，相当于多了一层防护，能降低恶意客户端冒充的风险。
• 权限与配额差异：不少服务商对机密客户端和公开客户端设置了不同的权限范围或API调用配额。比如机密客户端可能能访问更敏感的接口，或者拥有更高的调用额度。如果你的应用需要这些额外权限，就必须采用客户端凭证模式。
• 审计溯源更精准：使用客户端凭证时，服务端能更清晰地追踪每个客户端的请求行为。在需要审计、排查问题的时候，机密客户端的身份标识更明确，更容易定位到具体的应用或开发者，而仅靠客户端ID的公开客户端溯源能力较弱。
• 兼容现有系统：如果你的应用之前就是基于机密客户端模式开发的，切换到PKCE可能需要修改认证流程、调整代码逻辑。为了避免重构成本，继续使用客户端凭证模式会更高效，尤其是在服务商允许两种方式共存的情况下。
• 合规要求限制：某些行业或企业内部的合规规则，可能要求必须使用客户端凭证来确保客户端身份的强验证，即使PKCE能满足安全需求，也得遵循合规要求选用客户端凭证模式。

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