【翻译】单点登录与IOS11

本文翻译自 https://www.pingidentity.com/en/company/blog/2017/08/08/single_sign-on_and_ios_11.html

嗨，认证服务架构师们，你们是否察觉到即将到来的新版iOS和macOS中的一些变化？这些变化发生在2017年7月份并且可能会影响到你所在的公司单点登录（SSO）系统的用户体验。

当前（博客发布时间是2017年8月，译者注）safari的最新beta版本已经加强了对跨域用户信息追踪（cross-domain tracking of users）的限制。这是通过在浏览器状态机制中添加额外的限制（restrictions）——特别是cookies和HTML5 local storage机制——来完成的。而大多数机构正是通过以上的机制来实现单点登录（SSO）。

单点登录（SSO），是指这样一种能力：仅需进行一次认证即可使用户的认证状态被多个网站或手机应用识别，期间不需要用户再次提供登录凭证，在技术上也可称为一种“跨域追踪系统”（cross-domain tracking system）。

在本文中，我们将谈及这些即将到来的safari的变化，以及原生应用将会有哪些影响。

当前的最佳实践（指IOS11以前的版本，译者注）

行业推荐的方案是由基于web的认证服务器来完成认证工作，而不是由App自己去获取用户认证凭证。这样做有以下好处：
- App无法接触到用户的认证凭证信息（例如用户名密码等，译者注）
- 认证状态信息可以在多个App之间共享
- 认证过程可以升级进化（例如添加多因素认证），而不需要在App中加入额外的变更
- 用户可以只授予App部分权限
- App的权限可以被撤回，而不需要变更密码或者关闭其它App（breaking other applications）

像Oauth 2.0和OpenID Connect这样的协议就是为了让此类过程变得标准而规范，并具有“互操作性”（interoperability）而设计的。

IETF（互联网工程任务组，负责互联网标准的开发和推动，译者注）也发布了一些关于在原生App之中使用上述协议的涉及安全性和用户体验的最佳实践。有时这些最佳实践会涉及“AppAuth”，这是一个针对iOS和Android的开源类库。OpenID基金会持有并维护这些类库以支持开发者们实现OpenID Connect时参考上述这些最佳实践。

避免使用内嵌浏览器（embedded browser，此处特指非系统默认浏览器，译者注）是这些最佳实践中所重点提及的一项内容。不像系统浏览器，内嵌浏览器提供了对浏览器的完全的控制能力，例如App可以向浏览器中注入JavaScript，以及查看或修改页面内容。这种级别的控制使得App可以窃取用户从浏览器输入的凭证或其它信息。正因为有这样的风险，使得内嵌浏览器被放置于沙盒之中，没有访问系统级别的状态和用户凭证的权限。

在iOS9中，苹果公司新增了一个新的机制名字叫做SFSafariViewController(SVC)。与老版本的内嵌浏览器功能不一样的是，SVC使App不再具有查看或者控制web内容的能力。由于SVC被当做系统浏览器的一个分离的标签页（separate ‘tab’）。系统允许它访问cookies和用户凭证信息。

（SFSafariViewController也是运行于app内部，被称为 In-App Browser，与Embedded Browser 不是一个概念，译者注）

iOS 11 的变化

然而，跨App间共享一个浏览器会被用于追踪用户和设备信息而用户对此毫无察觉，这也是苹果公司历史上曾极力避免的。苹果公司在iOS11中设计了一系列新的特性以提高隐私保护同时提供更好的用户体验。

macOS中的桌面浏览器和iOS中的移动浏览器正在以一种全新的方式来沙箱化管理cookies和其它本地状态。当一个web站点从第三方域名读取脚本（script）或者其它资源时，由这些资源设置的cookies现在可能会被放置于沙箱之中，这样一来它们（指cookies，译者注）将独立于刚才提高的web站点而单独存在。举个例子，一个广告系统将不再能够通过cookies来追踪用户行为了，因为每个使用了此广告系统的web站点将会表现为在一个新的浏览器之中一样。

（以下这两段没理解作者想要表达什么意思）

Not all domains are sandboxed in this way. Individual user behavior is used to determine whether the user has an active relationship with the third party, and a third party which the user interacts with may still have a single global version of state.

As user authentication is normally tracked through such cookies, that means each separate service requesting authentication may not appear to your identity provider as if it’s a new browser. The heuristics and behavior of this functionality are still potentially fluctuating during beta, so further discussion of this topic will have to wait until iOS 11 is released.

对原生App的影响

从iOS11开始，使用SVC时将不会再共享cookies和其它状态信息了。取而代之的是，每个App会拥有它们自己的持久化cookie store。

这个变化允许像OpenID Connect和SAML这样的协议继续生效，但对SSO功能会有所影响。由于每个App拥有它们自己独立的cookie store，它们看起来就像是在不同的移动设备上。这样一来的结果就是很多App的用户体验会受到影响，因为用户需要在使用每个App时都要重新输入他们的凭证信息，这会导致很严重的问题。

在iOS11的初始beta版本中并没有明显的备选方案可以采用，对用户体验和安全性的影响开始受到关注。然而，在iOS11 beta3版本中增加了一种全新的机制去改善这一类认证状态的问题，名字叫做“SFAuthenticationSession”。此接口像极了SFSafariViewController，它受到了更多的限制以及增加了一个权限确认的操作。

---

如果用户同意让App使用第三方服务来登录，系统会给用户提供一个UI（用户界面）同时赋予它访问系统cookies的权限。这种用户体验表现出来就像是在iOS10里的SVC，但现在用户可以得知这一行为并对其进行授权。

下面的表格展示了各种集成接入方式在各个iOS版本中的可用状态，以及它们所提供的特性功能

Mobile Safari 看起来是个不错的选择并且提供了很好的向下兼容性，但历史上那些曾经尝试使用这种集成接入方式的App，在AppStore审查过程中遇到过一些问题。

分析

在将来，最佳实践可能会变成以下模样：
- 如果设备运行在iOS11，则选择SFAuthenticationSession，
- 如果设备运行在iOS9或iOS10，则用SFSafariViewController，
- 如果设备运行iOS8或者更早的版本（并且你的App打算支持这些用户）时，则使用Mobile Safari来打开认证页面。

当前的beta版本中的SFAuthenticationSession实现还仍然存在一些已知的问题，这些问题使得我们还不能明确地推荐App去支持iOS11。这些问题将很有可能会在iOS11的正式发行版中得到解决（由于翻译时iOS11已推出了正式版，因此那些问题已经不存在，就不翻译了，译者注）。

结论

如果你所开发的应用程序依赖于像AppAuth这样的类库，那么你只需更新这些类库的版本号即可支持上述那些新特性。对iOS11的支持，现已添加到 iOS 11-specific 分支中（截至翻译时，已经没了，取而代之的是iOS12的分支）。

如果你的应用没有依赖上面介绍的类库，那么现在正好可以重新评估一下AppAuth是否适合你的应用程序。

正如以往，在iOS11 beta版本中测试并上报你所遇到的问题给苹果公司，会帮助你的用户在升级到最新的发行版时拥有一个平滑的升级体验。