2.3. 客户端重定向端点

客户端重定向端点（又称“重定向端点”）是客户端的一个 URI。授权服务器完成与资源所有者的交互后，将用户代理重定向回到该 URI。

在客户端注册的过程中，客户端在授权服务器上预先建立了若干个重定向端点。授权服务器将用户代理重定向到这些端点之一。

重定向 URI 必须是如 [RFC3986] 第 4.3 节所定义的绝对 URI。重定向 URI 可以包含一个查询字符串部分（附录 C.1），后续在添加其它查询参数时必须保留该部分。重定向 URI 禁止包含片段部分。

2.3.1. 注册要求

授权服务器必须要求客户端注册其完整的重定向 URI（包括路径部分）。如果授权请求所指定的重定向 URI 不能精确匹配注册时的重定向 URI，那么授权服务器必须拒绝该请求。回环的重定向是一个例外，其 URI 的端口部分可以不精确匹配，详见第 4.1.1 节。

授权服务器可以允许客户端注册多个重定向 URI。

重定向 URI 的注册可以在 OAuth 流程外进行，例如在授权服务器上手动配置客户端信息；也可以在运行时进行，例如推送授权请求 [RFC9126] 中的初始 POST 请求。

对于基于私用 URI 方案的重定向 URI，授权服务器应该执行第 8.4.3 节的要求，即客户端使用基于反向域名的方案。按最低限度来说，任何不包含点号字符（.）的私用 URI 方案都应该被拒绝。

抗碰撞是上述方案的优点之一。另外，当两个应用（其一是恶意应用）争抢同一私用 URI 方案时，这也有助于判明所有权的归属。例如，如果两个应用都声称自己使用 com.example.app，example.com 的所有者就可以向应用商店的运营方申请移除伪造的应用。如果使用通用 URI 方案，那么此类申请就较难以验证。

客户端禁止暴露如第 7.12 节所述的“开放式重定向 URL”。这种 URL 可以将用户浏览器引导至查询参数中的任意 URI，从而导致授权码和访问令牌被渗透。

客户端可以使用 state 请求参数，来实现请求的差异化，而非对不同请求使用不同重定向 URI。

如果不要求注册重定向 URI，那么攻击者就可以将授权端点当作开放式重定向 URL，如第 7.12 节所述。

2.3.2. 多个重定向 URI

如果客户端注册了多个重定向 URI，那么客户端必须在授权请求中使用 redirect_uri 请求参数（第 4.1.1 节）指定重定向 URI。如果客户端只注册了一个重定向 URI，那么 redirect_uri 请求参数就是可选的。

2.3.3. 防止 CSRF 攻击

客户端必须防止跨站请求伪造（CSRF）攻击。在本规范的语境中，CSRF 指的是：重定向端点所收到的请求不来自授权服务器，而是来自恶意的第三方（详见 [RFC6819] 的第 4.4.1.8 节）。客户端如果已经确保了授权服务器支持 code_challenge 参数，那么就可以依赖该机制提供的 CSRF 保护。在 OpenID Connect 流程中，对 nonce 参数的验证也提供了 CSRF 保护。如果不靠这些保护机制，那么就必须在 state 参数中携带与用户代理安全绑定的一次性 CSRF 令牌，来实现 CSRF 保护（见第 7.9 节）。

2.3.4. 防止混淆攻击

如果 OAuth 客户端只能和一台授权服务器交互，那么就不必防止混淆攻击。但如果 OAuth 客户端能和两台或多台授权服务器交互，那么客户端就必须防止混淆攻击。为了防止混淆攻击，客户端处理的重定向响应必须来自它发送了对应请求的令牌发行方，并且其只能源自发起该授权请求的用户代理。

第 7.13 节详细描述了两种防止混淆攻击的方法。

2.3.5. 无效端点

如果重定向 URI 缺失、无效或不匹配，导致授权请求验证失败，授权服务器应该将该错误告知资源所有者，并且禁止自动将用户代理重定向到无效的重定向 URI。

2.3.6. 端点内容

发往客户端端点的重定向请求通常以 HTML 文档为响应，并且由用户代理处理。如果 HTML 响应被直接作为重定向请求的结果，那么 HTML 文档中包含的任何脚本，在其执行时，都能够完全访问到重定向 URI 和其中的重要信息（例如授权码）。此外，包含授权码的请求 URL 可能会被携带在 HTTP Referer 头部中，然后发送给页面上加载的所有图像、样式表和其他元素。

客户端不应该在重定向 URI 端点的响应中包含任何第三方脚本（例如第三方分析、社交插件和广告网络）。相反，它应该从 URI 中提取重要信息，并将用户代理再次重定向到另一个端点，从而不暴露（URI 中或别处的）重要信息。如果包含了第三方脚本，那么客户端必须确保自己的（用于从 URI 中提取并移除凭据的）脚本会首先执行。