附录 B. 平台特定实现细节
本文档主要以通用方式定义最佳实践, 并引用多种环境中常见可用的技术. 本非规范性章节记录这些最佳实践在各种操作系统上的实现细节.
本文中的实现细节在发布时被认为是准确的, 但很可能会随时间变化. 希望此类变化不会使文档其余部分的通用原则失效; 若发生冲突, 应以这些原则为准.
B.1. iOS 实现细节
App 可以通过 "SFSafariViewController" 类或其后继者 "SFAuthenticationSession" 在浏览器中发起授权请求, 且用户无需离开该 app; 它们实现了 in-app browser tab 模式. 在没有 in-app browser tab 功能的旧版 iOS 上, 可以使用 Safari 处理请求.
为接收授权响应, 私用 URI 方案 (称为 "custom URL scheme") 重定向和声明的 "https" 方案 URI (称为 "Universal Links") 都是可行选择. App 可以通过应用的属性列表文件 "Info.plist" 中的 "CFBundleURLTypes" 键声明私用 URI 方案, 并通过 Universal Links 功能, 使用 app 中的 entitlement 文件和托管在域上的 association 文件声明 "https" 方案 URI.
由于操作系统提供所有权证明, 在 iOS 9 及以上版本中, 声明的 "https" 方案 URI 是首选重定向方式.
AppAuth for iOS and macOS [AppAuth.iOSmacOS] 库中包含完整的开源示例.
B.2. Android 实现细节
App 可以通过 Android Custom Tab 功能在浏览器中发起授权请求, 且用户无需离开该 app; 该功能实现了 in-app browser tab 模式. 当没有浏览器支持 Custom Tabs 时, 可以使用用户默认浏览器处理请求.
Android 浏览器供应商应支持 Custom Tabs 协议 (通过提供 "CustomTabsService" 类的实现), 以便为用户提供 in-app browser tab 用户体验优化. Chrome 是实现 Custom Tabs 的浏览器之一.
为接收授权响应, Android 通过 Implicit Intents 广泛支持私用 URI 方案. Android 6.0 及以上版本可通过 Android App Links 使用声明的 "https" 方案重定向 URI. 这两类重定向 URI 都在应用清单中注册.
AppAuth for Android [AppAuth.Android] 库中包含完整的开源示例.
B.3. Windows 实现细节
传统应用和 Universal Windows Platform (UWP) app 都可以在用户浏览器中执行授权请求. 传统应用通常使用回环重定向接收授权响应, 默认防火墙规则允许监听回环接口. 创建回环网络套接字时, app 应当设置 "SO_EXCLUSIVEADDRUSE" 套接字选项, 以防止其他 app 绑定到同一套接字.
UWP app 可以使用私用 URI 方案重定向从浏览器接收授权响应, 这会将 app 带到前台. 在该平台上此机制称为 "URI Activation"; URI 方案长度限制为 39 个字符, 并且可以包含 "." 字符, 因而可以使用较短的基于反向域名的方案 (如第 7.1 节所要求).
UWP app 也可以在 Single Sign-on (SSO) 模式下使用 Web Authentication Broker API, 这是专为授权流程设计的外部用户代理. Cookie 在 broker 的多次调用之间共享, 但不与用户首选浏览器共享; 这意味着即使用户在浏览器中已有活动会话, 仍需要重新登录, 但在 broker 中创建的会话可供后续使用该 broker 的 app 使用. 用户对其浏览器所做的个性化设置, 例如配置密码管理器, 可能在 broker 中不可用. 若要符合外部用户代理资格, broker 必须在 SSO 模式下使用.
若要在 SSO 模式下使用 Web Authentication Broker, 重定向 URI 必须采用 msapp://{appSID} 形式, 其中 "\{appSID\}" 是 app 的安全标识符 (SID), 可在 app 注册信息中找到, 或通过调用 "GetCurrentApplicationCallbackUri" 方法获得. 虽然 Windows 会对这类重定向强制执行 URI authority, 确保只有 SID 匹配的 app 能在 Windows 上接收响应, 但该 URI 方案可能会被其他平台上的 app 声明, 而这些平台不具备相同 authority; 因此, 出于安全目的, 应将这种重定向类型视为类似私用 URI 方案重定向.
展示这些模式的开源示例见 [SamplesForWindows].
B.4. macOS 实现细节
App 可以使用用于在浏览器中打开 URI 的平台 API, 在用户默认浏览器中发起授权请求.
为接收授权响应, 私用 URI 方案是 macOS 上很好的重定向 URI 选择, 因为用户会直接回到发起请求的 app. 这些方案使用 "CFBundleURLSchemes" 键注册在应用的 bundle 信息属性列表中. 回环 IP 重定向也是另一种可行选项, 默认防火墙规则允许监听回环接口.
AppAuth for iOS and macOS [AppAuth.iOSmacOS] 库中包含完整的开源示例.
B.5. Linux 实现细节
在用户默认浏览器中打开授权请求需要使用发行版特定命令: "xdg-open" 就是此类工具之一.
对于 Linux 上的桌面 app, 推荐使用回环重定向接收授权响应. 为防止其他 app 绑定到同一套接字, app 不应设置 "SO_REUSEPORT" 或 "SO_REUSEADDR" 套接字选项.