6. 从原生应用发起授权请求

需要用户授权的原生应用会按照 OAuth 2.0 [RFC6749] 第 4.1 节, 使用授权码授权类型创建授权请求 URI, 并使用能够由原生应用接收的重定向 URI. 对于原生应用授权请求, 重定向 URI 的功能类似于基于 Web 的授权请求中的重定向 URI.

不同之处在于, 原生应用使用的重定向 URI 会将授权响应返回给该 app, 而不是返回给 OAuth 客户端的服务器. 第 7 节记录了若干重定向 URI 选项, 可在不同平台上将授权响应返回给原生应用. 任何允许 app 接收 URI 并检查其参数的重定向 URI 都是可行的.

公共原生应用客户端必须实现 OAuth 的 Proof Key for Code Exchange (PKCE [RFC7636]) 扩展, 授权服务器也必须为此类客户端支持 PKCE, 原因详见第 8.1 节. 构造授权请求 URI 后, app 使用平台特定 API 在外部用户代理中打开该 URI.

通常使用的外部用户代理是默认浏览器, 即系统中配置为处理 "http" 和 "https" 方案 URI 的应用程序; 但是, 也可以使用不同的浏览器选择标准和其他类别的外部用户代理. 本最佳实践将浏览器作为原生应用推荐使用的外部用户代理.

也可以使用专为用户授权设计, 且能够像浏览器一样处理授权请求和响应的外部用户代理. 其他外部用户代理, 例如由授权服务器提供的原生 app, 可能满足本最佳实践提出的标准, 包括使用相同的重定向 URI 属性, 但其使用不在本规范范围内.

某些平台支持称为 "in-app browser tabs" 的浏览器功能, app 可在自身上下文中呈现浏览器标签页而无需切换 app, 但仍保留浏览器的关键优势, 例如共享认证状态和安全上下文. 在支持此功能的平台上, 出于可用性原因, 推荐 app 对授权请求使用 in-app browser tabs.