自建IDP实现Auth Code Flow with PKCE未白名单重定向URL的安全风险咨询

1. 风险真实存在，绝非小题大做 #

未校验重定向URL的授权码流程确实会引发严重的中间人攻击，典型场景如下：

• 攻击者构造恶意授权请求，将redirect_uri设置为自己控制的域名，诱导用户点击并完成身份验证。
• IDP会直接把授权码发送到攻击者的URL，而攻击者作为该请求的发起者，早已生成对应的code_challenge和code_verifier。
• 攻击者拿到授权码后，可直接用自己的code_verifier向IDP换取用户访问令牌，完全绕过PKCE的防护。

此外，即使是私有客户端，未限制重定向URL也会导致授权码泄露风险——比如授权码被意外转发到恶意站点，结合其他攻击手段可能被滥用。

2. PKCE无法覆盖这个漏洞 #

PKCE的核心作用是防止授权码在传输过程中被截获后，第三方无法用该授权码换取令牌（因为没有客户端生成的code_verifier）。但如果攻击者能直接让IDP把授权码发送到自己控制的站点，他们本身就是授权请求的发起者，自然持有对应的code_verifier，此时PKCE完全起不到防护作用。

PKCE是OAuth 2.0的补充安全机制，从来不是重定向URL校验的替代品。

3. 关于RFC的说明 #

RFC7636（PKCE规范）未提及重定向URL白名单，是因为这属于OAuth 2.0核心规范的强制要求。核心规范明确规定：

授权服务器必须校验请求中的redirect_uri是否与客户端注册时提交的地址一致，不一致则拒绝请求。

不管是公开还是私有客户端，重定向URL白名单都是基础安全要求，与PKCE无关。

4. 整改建议 #

• 紧急实现重定向URL白名单校验：所有客户端注册时必须提交允许的重定向地址，授权端点严格校验请求中的redirect_uri，不匹配则直接拒绝。
• 区分公开/私有客户端：公开客户端（如SPA、原生APP）禁用客户端密钥，仅依赖PKCE+重定向校验；私有客户端（如后端服务）需配置密钥，同时强制校验重定向URL。
• 排查现有客户端，强制补全重定向URL白名单配置，禁止无限制的客户端存在。

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