7. 在原生应用中接收授权响应
原生应用可使用多种重定向 URI 选项从浏览器接收授权响应, 其可用性和用户体验因平台而异. 为了完整支持此最佳实践, 授权服务器必须至少向原生应用提供以下小节描述的三种重定向 URI 选项.
原生应用可以使用最符合自身需求的任何重定向选项, 同时考虑平台特定的实现细节.
7.1. 私用 URI 方案重定向
许多移动和桌面计算平台支持通过 URI 进行 app 间通信, 方法是允许 app 注册私用 URI 方案 (有时通俗称为 "custom URL schemes"), 例如 "com.example.app".
当浏览器或另一个 app 尝试加载带有私用 URI 方案的 URI 时, 注册该方案的 app 会被启动以处理请求. 若要使用私用 URI 方案重定向执行 OAuth 2.0 授权请求, 原生应用会用标准授权请求启动浏览器, 但其中的重定向 URI 使用该应用已向操作系统注册的私用 URI 方案.
选择与 app 关联的 URI 方案时, app 必须使用基于其所控制域名的 URI 方案, 并以反向顺序表示, 如 [RFC7595] 第 3.8 节对私用 URI 方案的建议. 例如, 控制域名 "app.example.com" 的 app 可以使用 "com.example.app" 作为其方案.
某些授权服务器基于域名分配客户端标识符, 例如 "client1234.usercontent.example.net"; 这些标识符也可以用相同方式反转后作为方案的域名. 但是, "myapp" 这样的方案不满足此要求, 因为它不是基于域名. 当同一发布者有多个 app 时, 必须注意确保每个方案在该组内唯一.
在使用基于反向域名的 app 标识符的平台上, 这些标识符可以复用为 OAuth 重定向的私用 URI 方案, 以帮助避免此问题. 遵循 [RFC3986] 第 3.2 节要求, 由于私用 URI 方案重定向没有命名权威, 因此方案组件之后只出现一个斜杠 ("/").
使用私用 URI 方案的完整重定向 URI 示例:
com.example.app:/oauth2redirect/example-provider
当授权服务器完成请求时, 它会像通常一样重定向到客户端的重定向 URI. 由于该重定向 URI 使用私用 URI 方案, 操作系统会启动原生应用, 并将该 URI 作为启动参数传入. 随后, 原生应用按正常流程处理授权响应.
7.2. 声明的 "https" 方案 URI 重定向
某些操作系统允许 app 声明其所控制域中的 "https" 方案 [RFC7230] URI. 当浏览器遇到已声明 URI 时, 不会在浏览器中加载页面, 而是启动原生应用并将该 URI 作为启动参数提供. 原生应用可以将此类 URI 用作重定向 URI. 对授权服务器而言, 它们与常规基于 Web 的客户端重定向 URI 无法区分.
示例:
https://app.example.com/oauth2redirect/example-provider
由于仅凭重定向 URI 不足以区分公共原生应用客户端和机密 Web 客户端, 第 8.4 节要求在客户端注册期间记录客户端类型, 以便服务器确定客户端类型并采取相应处理.
与其他原生应用重定向选项相比, app 声明的 "https" 方案重定向 URI 有一些优势, 因为操作系统向授权服务器保证了目标 app 的身份. 因此, 在可能的情况下, 原生应用应当优先使用它们.
7.3. 回环接口重定向
能够在不需要特殊权限的情况下打开回环网络接口端口的原生应用 (通常是桌面操作系统上的应用) 可以使用回环接口接收 OAuth 重定向. 回环重定向 URI 使用 "http" 方案, 并使用回环 IP 字面量和客户端正在监听的任意端口构造.
也就是说, IPv4 使用 http://127.0.0.1:{port}/{path}, IPv6 使用 http://[::1]:{port}/{path}.
使用随机分配端口的 IPv4 回环接口重定向示例:
http://127.0.0.1:51004/oauth2redirect/example-provider
使用随机分配端口的 IPv6 回环接口重定向示例:
http://[::1]:61023/oauth2redirect/example-provider
对于回环 IP 重定向 URI, 授权服务器必须允许在请求时指定任意端口, 以适应客户端在请求时从操作系统获取可用临时端口的情况.
客户端不应假定设备支持某个特定版本的 Internet Protocol. 推荐客户端尝试同时使用 IPv4 和 IPv6 绑定到回环接口, 并使用其中可用者.