4. 概述
对于原生应用中的用户授权, 当前最佳实践是在外部用户代理 (通常是浏览器) 中执行 OAuth 授权请求, 而不是在嵌入式用户代理 (例如使用 web-view 实现的用户代理) 中执行.
过去, 原生应用通常使用嵌入式用户代理 (常以 web-view 实现) 发起 OAuth 授权请求. 这种方法有许多缺点, 包括宿主 app 能够复制用户凭据和 cookie, 以及用户需要在每个 app 中从头认证. 关于使用嵌入式用户代理进行 OAuth 的缺点, 更深入的分析见第 8.12 节.
使用浏览器的原生应用授权请求更安全, 并且可以利用用户的认证状态. 能够使用浏览器中的现有认证会话可启用单点登录, 因为用户每次使用新 app 时无需重新向授权服务器认证 (除非授权服务器策略要求).
支持原生应用与浏览器之间的授权流程无需更改 OAuth 协议本身, 因为 OAuth 授权请求和响应已经以 URI 的形式定义. 这也涵盖可用于 app 间通信的 URI. 某些假定所有客户端都是机密 Web 客户端的 OAuth 服务器实现, 需要增加对公共原生应用客户端以及它们所使用重定向 URI 类型的理解, 以支持此最佳实践.
4.1. 使用浏览器的原生应用授权流程
+``````````````````````````````~+
| User Device |
| |
| +--------------------------+ | (5) Authorization +---------------+
| | | | Code | |
| | Client App |---------------------->| Token |
| | |<----------------------| Endpoint |
| +--------------------------+ | (6) Access Token, | |
| | ^ | Refresh Token +---------------+
| | | |
| | | |
| | (1) | (4) |
| | Authorizat- | Authoriza- |
| | ion Request | tion Code |
| | | |
| | | |
| v | |
| +---------------------------+ | (2) Authorization +---------------+
| | | | Request | |
| | Browser |--------------------->| Authorization |
| | |<---------------------| Endpoint |
| +---------------------------+ | (3) Authorization | |
| | Code +---------------+
+``````````````````````````````~+
图 1: 通过外部用户代理进行原生应用授权
图 1 展示了原生应用和浏览器之间用于授权用户的交互.
(1) 客户端 app 打开包含授权请求的浏览器标签页.
(2) 授权端点接收授权请求, 对用户进行认证, 并获得授权. 认证用户可能涉及链接到其他认证系统.
(3) 授权服务器向重定向 URI 签发授权码.
(4) 客户端从重定向 URI 接收授权码.
(5) 客户端 app 将授权码提交给令牌端点.
(6) 令牌端点验证授权码并签发所请求的令牌.