登录方式的演变过程

说到一键登录，我们需要先熟悉一下登录方式的演变过程，大致可以分为四个阶段。

阶段一：账号+密码登录

账号+密码登录是传统的登录方式，也是早期市场上最普遍的登录方式，用户凭自己注册时设置账号和密码在登录时使用，虽然简单粗暴，也确实能够满足用户鉴权的场景，但缺点也是显而易见：

(资料图)

用户层面：

记忆成本高：要求用户记住自己的账号和密码，当用户忘记账户或密码时，就只能通过繁琐的“找回密码”来重新设置密码，给用户带来了不佳的体验。账号泄漏影响面广：用户为了降低记忆成本，通常会在不同的平台使用同一套账号密码，一旦某个平台的账户密码泄漏了，会殃及用户使用的其他平台。

企业层面：

恶意注册：既不与设备绑定也不与身份绑定，意味着一个用户可以注册多个不同的账号，耗费服务成本和运营成本，也影响了业务数据的准确性。

出于企业的角度，恶意注册带来的问题尤为明显，为了解决这个问题需要用一个和用户身份强相关的东西来做账号。但是究竟用什么呢？总不能用身份证号吧，直到手机号实名制政策的发布，手机号成为我们另一个身份证明，这个问题终于得到了解决。

阶段二：手机号+验证码

手机号+验证码是当前应用最广的登录方式，和账号+密码相比，它不要用户再去记自己的账号密码，也增加了安全性，可以更好的验证用户身份并防止恶意注册。这种方式还可以把登录和注册流程进行结合，若登录时发现手机号还未注册，则先用手机号注册好之后再进行登录，一切都是静默进行，用户无感，极大的降低了用户的操作成本。但是这种方式依然存在缺点：

输入成本高：需要输入手机号 ➡️ 获取并等待验证码短信 ➡️ 输入验证码 ➡️ 点击登录。这套流程走完之后大概在20秒以上，操作步骤多。依赖短信：若因为异常未收到短信就登录不成功（比如手机号被加入了黑名单，导致收不到验证码），造成用户在注册阶段就流失。存在验证码泄漏风险：如果有人知道你的手机号，并且窃取了验证码，账号就会被盗用

到这一步，一些有心人会回过头想一下：

为什么需要验证码？验证码的作用是确认手机号是用户本人的，那么除了验证码还有那些方式可以证明手机号是用户本人的？如果能提前获取到用户当前使用的真实手机号，然后对用户输入的手机号进行验证，是不是同样可以证明呢？

阶段三：本机号码认证

虽然操作系统限制用户端无法直接获取手机号，但是运营商可以通过sim卡流量数据查询到，因此号码认证应运而生。

现在国内三大运营商（移动、联通、电信）都已经开放了相关的能力：用户输入手机号之后请求运营商接口，运营商拿到用户输入的手机号并通过请求网络流量查询 sim 卡对应的手机号，判断两者是否一致，即可完成登录，极大的简化了登录流程，提高了安全性。

再进一步想，既然运营商可以查询到用户当前使用的手机号，直接让运营商返回用户当前手机号码，让用户直接用当前手机号码登录，不就可以进一步减少输入成本，变得更加便捷吗？于是运营商也开放了直接返回手机号的能力。

阶段四：一键登录

一键登录简单来讲就是获取当前用户当前手机号，直接用该手机号进行登录，这种登录方式特点是一键式，完美解决了上述登录方式存在记忆成本、输入成本、泄漏风险、恶意注册等所有问题，登录的整个过程2秒左右，也极大程度降低了注册登录环节的用户流失。

小结

一键登录的基本原理

要使用一键登录需要在用户端内集成运营商的 SDK,三大运营商提供的授权流程也都是一致，下方是一键登录的流程图：

一键登录流程图

这里对一些关键步骤进行说明：

1.2 判断手机号归属运营商：虽然用户端不能获取手机号，但是 ios、Android 操作系统提供了蜂窝煤网络信息的获取方法，可以从中解析得知用户当前手机号归属哪个运营商。并且由于需要获取手机蜂窝煤网络信息，也就是说需要通过手机流量上网才能支持一键登录。 2.1 对应运营商发起预取号：预取号的目的是获取手机号掩码，也就是手机号的前三后四位，如186****5385，这个手机号掩码需要在一键登录授权页面展示给用户看，因为预取号需要通过运营商服务端才能获取，所以会有一定的等待时间，因此为了提升用户体验，可以在打开应用的的时候就去获取，然后将其缓存下来。 3.3获取登录 Token ：因为手机号属于用户的敏感信息，运营商为满足国家相关法律法规的规范要求，且保障用户在知情的情况下清晰地了解并同意授权用户端获取该信息，因此拉起授权页面后需要用户勾选运营商协议。用户确认授权一键登录之后，用户端会向运营商发起请求以获取登录 Token，运营商服务端会返回一个登录 Token 给用户端，应用再通过自己的业务服务端拿着这个 Token 找运营商换取手机号码。 4.3返回手机号：成功返回手机号后，可以说是已经登录成功了，应用就需要维护自己用户的登录状态，这里可以采用传统的 Session 机制，也可以使用 JWT 机制。

这里还存在一个安全问题：

4.1提交登录 Token 到业务服务端：一些不法用户如果伪造一个登录 Token 向业务服务端提交请求，业务服务端再向运营商服务端发起请求，虽然这个 Token 可以最终在运营商侧会被阻止，但是不免浪费资源，给服务端带来压力。关于这一点也有解决办法，业务服务端先生成一个随机数，然后用户端向业务服务端提交时带着这个随机数，业务服务端验证这个随机数，就可以很大程度避免这个问题。