无论在现实世界还是互联网中,如何证明一个人是「自己」这个问题令无数聪明人绞尽脑汁。为了更好地提供差异化服务与保存个人数据,同时保证数据安全性,用户想要使用互联网世界上的绝大多数服务,不仅需要证明「我是我」,还需要证明「我是真的我」,不是爬虫等机器人在使用你的账号,我们常见的各种验证码正是为此而生。

在第三方登录出现之前,大部分用户账户注册与登录流程都是双输的局面:

  • 用户方面:为了安全性而设置的密码往往复杂又冗余,既容易忘记输入又很麻烦,同时各种难度的验证码和各种验证问题,不仅过滤机器人也能过滤真人,加上手机验证码等等繁琐步骤,让注册登录变得异常烦心。
  • 服务商方面:加上各种验证步骤会明显降低用户体验,可是不加又会导致用户账户不安全和各种机器人账号泛滥,更不用说还要自己探索实现各种验证步骤,一不小心就会出现漏洞。很多时候最后这些繁琐的步骤也没有挡住日益智能的机器人,反而挡住了很多正常用户。
繁琐的验证步骤

第三方登录(OIDC)

为了解决上面提到的各种问题,开放授权(OAuth)在 2010 年应运而生。简单来讲它是一个开放标准,允许用户在不提供密码的情况下,授权接入了 A 网站第三方登录支持的第三方应用,访问自己在 A 网站上的特定数据

接着为了解决安全性问题,OAuth 2.0 诞生了,同时有人发现了这个标准很适合用来登录验证用户身份,于是基于此延伸的标准,专门解决第三方客户端标使用身份认证的问题的 OIDC(OpenID Connect) 诞生了。现在我们见到的大多数第三方登录都是基于 OIDC 或者利用 OAuth 2.0 修改实现。

常见的第三方登录

第三方登录的原理

因为 QQ/微信/微博等平台(以下简称第一方平台)拥有完整的登录验证步骤,用户在上面已经充分地证明了「我是真的我」。所以,第三方网站与服务只要接入了这些平台的第三方登录 SDK(开发组件),用户点击第三方登录按钮时:

  1. 网站或服务会通过第三方登录 SDK 向第一方平台发送登录请求。
  2. 第一方平台接收到登录请求,确认用户设备上有没有已经登录的第一方平台账户,如果没有用户需要先手动登录第一方平台。
  3. 如果用户已经在设备上登录了第一方平台账户,那么第一方平台会返回唯一的不变的 ID(OpenID)
  4. 第三方网站与服务将这个 ID 储存到自己的服务器上,以后就能通过这个 ID 确认用户了。
第三方登录流程图

我们常见的用 QQ 登录/用微博登录等按钮就是这么来的。

这是国内常用的简化方法,更多相关资料可以查看 IBM的介绍

第三方登录的好处

第三方登录打破了之前双输的局面,给用户和第三方服务商带来了不少的好处。

对用户而言,只需要在设备上登录第一方账户就能轻松注册登录大多数第三方网站与服务,免去了记不同密码和各种麻烦的验证步骤,省心又省时。

对第三方服务商而言,首先不用再费心费力实现各种验证步骤,全都交给第一方,只需要等待他们返回 OpenID 就行,接着是不用再保存用户的密码信息,免去了信息泄露的风险。

使用第三方登录还能带来账户安全性的提升,有效避免「钓鱼」与「撞库」情况。

用户根本没有在第三方网站有密码,也就没有需要找回密码的情况,黑客也就更难利用假的重置密码邮件等去「钓出」用户的密码。

第三方网站不保存用户的密码,即使数据库被黑客攻破也拿不到用户密码,免去黑客拿到密码攻击用户其他网站的「撞库」问题(很多用户喜欢在不同网站用同一个密码)。

网站或服务能通过第三方登录获取什么信息

很多人关心的另一个重点是自己点击第三方登录按钮后第一方平台会向第三方网站发送什么信息

其实,当你首次在某个网站点击第三方登录时,第一方平台在确认的时候会显示网站能够获得除了 OpenID 或者 Token/Code 等数据外的数据,就像下面的微信第三方登录就只会提供昵称、头像、地区、性别四个信息给第三方。

微信登录还能随机头像和昵称

只要在登录确认时没有标注,第三方平台不会索取,第一方平台也不会提供更多的类似手机号码、真实姓名、地址、等隐私数据,因为没有必要——第三方平台只需要一个固定不变的标识符来标记用户个人数据,出卖隐私信息给没有太大利益关系的第三方平台也不能给第一方平台带来额外的利益。

Sign In with Apple

第三方登录现在已经成为了主流的登录方式,为了给自家用户带来更好的跨平台与跨设备体验,苹果在今年的 WWDC2019 推出了属于自己的第三方登录服务 —— Sign In with Apple。由于有了前人成熟的基础,这次苹果在第三方登录上更进一步,无论是从安全性还是便捷性上都是如此。

Sign In with Apple 使用方法

当用户打开一个支持 Sign In with Apple 的应用,他们会看到类似下面的按钮:

Sign In with Apple 按钮

点击按钮后,在弹出窗口中系统会展示登录应用后应用能够获取的用户信息,基本上只有用户名和邮箱。

登录确认框

而在邮箱上苹果进行了独特的操作,允许用户指定或者生成一个随机邮箱。随机邮箱很好地避免了邮箱泄漏带来的垃圾邮件骚扰问题,重要的是随机生成的邮箱也可以收到邮件和回复收到的邮件(会转发到用户绑定到 Apple ID 的邮箱),苹果也特别表明了在投递到真实邮箱后将不会保留任何邮件数据。

随机邮箱

确认登录信息后,用户只需要点击继续即可使用 FaceID或者指纹确认完成登录,整个登录流程只有两三下点击操作,不包含任何需要用户输入和验证的流程。

开发者通过 Sign In with Apple 获取的信息

那么对开发者而言(用户也比较关心)使用 Sign In with Apple 能获取到什么用户信息呢?苹果在 WWDC 的 Special Events 上专门展示了这点:

Sign In with Apple 分享的信息

图上就是开发者能拿到的用户信息,一个必须有的标识身份的随机生成的与用户信息无关的 OpenID,用户的姓名和邮箱地址。这些信息和其他第三方登录分享的信息没有太大的区别。

此外,最令开发者高兴的一点是整个登录流程不需要任何自己参与的工作。只需要把按钮放到应用里,不用额外的邮件认证操作,不用保存用户密码,不用费心,自己实现两步验证,甚至不用验证用户是否是机器人(苹果宣称使用了特殊的算法来识别机器人,具体内容没有公开以免被针对性破解),这一切通通后台交给苹果来处理。

Sign In with Apple 对用户的影响

根据苹果的政策,只要应用使用了第三方登录(比如 QQ 登录或者 Google 登录)就一定要添加 Sign In with Apple 按钮,否则不能上架 App Store。并且建议应用将按钮突出显示,比如放在首位或者直接做成下面这种:

把其他第三方登录隐藏起来

可以预见,未来所有应用都会支持 Sign In with Apple,那么对我们而言这又有什么影响呢?

首先是绝大部分人的苹果设备都登录了 Apple ID,所以无论在哪台设备上登录什么应用,流程都会被简化为点一下按钮,就连 Safari 上打开支持的网站也会有原生的带指纹识别的确认框,这极大提升了多设备切换使用的用户体验。

然后,Sign In with Apple 目前只支持所有苹果系统(iOS,MacOS,TvOS,WatchOS 等),至于其他平台(Android,Windows 等)并没有提供 SDK。但是苹果提供了 JavaScript SDK 让用户在浏览器网站上也能使用 Sign In with Apple,第三方平台可以利用这个功能去实现原生的 Sign In with Apple,但这比较曲折和麻烦,取决于其他平台开发者适配的动力。不然用户切换到其他平台的设备就只能使用登录使用网页版的服务了。

Safari 的原生支持

另外,按照政策谷歌或者腾讯在 iOS 上的应用也需要添加 Sign In with Apple,这带来了几个麻烦:

首先是用户数据怎么迁移,比如用户之前用微信登录的王者荣耀,现在如果想要改用 Sign In with Apple,那么游戏数据能否迁移?

苹果官方还没有给出相应的解决方案,把这个问题扔给了公司与开发者,估计大部分公司不会专门为了这个去制作建议用户数据的功能,最后 Sign In with Apple 沦落为一个装饰性的按钮。

然后是两次验证的问题,比如我用 Sign In with Apple 登录 Google 应用后想要访问我的谷歌硬盘又需要用谷歌账号再登录一次。苹果也没有处理这个情况,大部分公司同样也不会专门为了这个去改变自己的验证流程,用户如果用了 Sign In with Apple 只能忍受在不同平台之间验证几次的问题。

关于国内用户

由于实名制的存在,在国内无论用户使用的是 Sign In with Apple 还是其他在国内提供服务的第三方登录平台,都要在登录后验证手机号码。因此即使用户使用了苹果提供的随机邮箱来避免自己被垃圾邮件困扰,也防不了实名验证下的骚扰电话。

总结

随着 FIDO2 等无密码登录技术的发展,未来或许我们连第三方登录按钮都不再需要,但目前它依然是最高效最便捷的用户登录流程,无论国内的第三方登录还是 Sign In with Apple 都是我们可以放心使用的安全登录方式。

但是,作为一个能够有效提升用户黏度的功能,在新用户越来越「值钱」的今天,国内的巨头们(阿里、腾讯)肯定不会任由苹果通过这个按钮分流掉他们的用户。这就是我们为什么基本看不见「使用百度登录」的按钮(日常使用的应用基本都被两大巨头瓜分了)。想要让用户在国内真正无虑地使用,Sign In with Apple 仍有很多的问题等待解决。