iOS11中，苹果的SafariServices新增了SFAuthenticationSession用于优化登录方式。其简单的原理就是，App可以通过苹果提供的API调起一个Safari页面，但这个页面和App并不在一个进程，而是一个单独的进程。所以这个机制就限制了App拿不到用户在页面上输入的任何信息，以及和服务端交互过程中服务端返回的任何信息，比如cookie等。但是，App在使用SFAuthenticationSession的时候，会需要预先配置一个domain，App内调起的Safari页面可以和真正的Safari共享这个domain下面的cookie。这样整个流程就可以走通了，比如用户在Safari内访问过accounts.google.com，并且做了登录，Safari保存了google.com下面的cookie，那App在使用SFAuthenticationSession打开accounts.google.com引导用户登录时，本地已经有了google.com下面的cookie，于是免去了用户输入用户名密码登录的过程。这样的好处很明显，比如用户手机上同时安装了很多个某公司同一系列的App，或者是使用某帐号OAuth登录的App，这些App很可能不在一个苹果开发者账号下面，无法共享keychain，那这种方式可以很便捷的在各个App之间共享登录态，用户在任意一个App内登录后，其余App都可以免去输入用户名密码的过程，获取到登录态。
如果需要服务端的登录流程满足这个feature的话，简单来说有两个问题需要解决：
第一，使用SFAuthenticationSession时设置的domain如果是a.test.com这个域名，那么，真正能和Safari共享的还是test.com下面的cookie，并不能共享a.test.com下面的cookie，服务端需要在test.com这个一级域名下面设置对应的cookie来实现共享。
第二，用户在Safari页面中登录完成后，前端需要跳转到一个特定的url，例如[test://loginfinish?token=******]这种格式，这样App才能获知用户已经在Safari页面中登录完成，并且拿到对应的登录信息。
目前Google系列的App基本支持了这项功能，可以下载iOS版本的谷歌地图，Gmail，谷歌翻译来体验这个功能。
目前可以提供的一个简单的技术方案就是，接入方请求一个类似于https://a.test.com?service=test的url，service在服务端和一个url scheme对应，这个scheme比如是com.test.apps12345678。服务端在用户登录完成后，下发token到test.com域名下，而后需要跳转到com.test.apps12345678://loginfinish?id=123456&token=******这个地址。这样客户端可以获取到id和token，从而可以进行后续的登录逻辑。下发cookie中的token是为了让用户在Safari中或者在别的App中可以获取到登录态，如果已经有token的cookie，前端页面最好给用户一个确认或者切换账号的提示，不要直接跳转。
网友评论