UC头条：扫码登录的原理和实现

1概述

在日常Web端产品的使用中，一般都会支持扫码登录，这种方式操作简单，相对传统的手机号登录等方式速度更快、安全性更高，还可以增加自家产品的粘合度。

2登录原理

扫码登录本质是解决将APP端的用户登录信息（通常是Token）通过扫码的形式安全稳定地同步给Web端。

1）用户打开Web端网页，进入扫码登录的界面；

2）从Web端服务器获取二维码的图并获取其状态；

3）Web端服务器在生成二维码时，会生成一个uuid和二维码进行关联，并将uuid存入db记录中；

4）用户打开APP端，对着二维码进行扫码授权操作；

5）APP客户端从二维码中读取到uuid，带着APP内的身份信息访问APP端服务器；

6）APP端服务器获取到用户的身份信息后，将用户id更新到db中对应uuid的记录中，此时Web服务器就能拿到对应的用户id，之后生成登录身份信息返回给浏览器，即用户在Web端完成了登录；

3实现方案

基于以上分析，我们可以将扫码登录分为两个步骤：获取扫码状态和获取用户登录信息。

3.1获取扫码状态

用户在Web端页面看到二维码信息后，会使用客户端进行扫码授权，而Web端需要尽快获取到二维码的状态(已扫码、已过期、已取消、已授权)并同步到网页中展示给用户,现在有3种方案：

3.1.1长链接

Web端访问服务器获取二维码状态时，服务器是阻塞了请求，等到二维码的状态变更后才会返回结果，这种请求都会有超时配置(通常是几分钟)，但又不能无限等待。

方案优点：

减少不必要的资源访问浪费；

可以准确区分恶意访问(扫描漏洞，后面的部分会对这部分进行阐述)并进行限流；

当二维码状态变更时，相对于下面的定时轮询方案有更快的响应速度；

方案缺点：

占用服务端大量连接数；

由于超时时间通常比较长，需要web端和nginx对这些请求进行特殊的超时配置；

3.1.2轮询

Web端每隔一个固定时间(为了更好的用户体验通常选择为1秒)访问服务器获取二维码的状态并进行展示。

方案优点：

符合常规思维，开发模式比较简单易维护；

相比阻塞等待方案能够快速释放服务端的连接；

对于服务端的变更升级也更加友好，因为变更升级会导致服务重启，采用阻塞方案则可能会造成部分连接断开；

方案缺点：

如果扫码登录请求访问量大，会导致服务端的访问量一直处于高位；

产生了大量的无用访问，造成资源浪费；

无法准确区分恶意访问并对其进行合理限流；

3.1.3长轮询

长轮询即结合了长链接和定时轮询的优点，Web端访问服务器获取二维码状态时，服务器依然会阻塞了请求，但是超时时间会相对比较短(比如15秒)，超时后Web端会继续发起请求，如此往复。

方案优点：

结合了阻塞等待和定时轮询的优点，削弱了两个方案的的缺点；

方案缺点：

让Web端开发逻辑更加复杂，相当于同时实现了两种方案；

3.1.4方案选择

三种方案各有优缺点，应该结合业务进行选择，先看看各大厂家的选择：

平台	方案
微信开放平台	长轮询
微信公众号	轮询
京东	轮询
淘宝&&天猫	轮询
百度	长轮询
B站	轮询
快手	长链接

从上面可以看出目前主流方案是定时轮询，这是由于扫码登录本身也是低频操作，并不会造成很大量的请求，但优点又比较突出。

3.2获取登录信息

当用户扫码登录后，Web服务器如何将用户信息（如Token）同步给Web端。

3.2.1返回Token

指直接返回用户登录信息Token。

方案优点：

流程简单，完成扫描授权后流程后直接结束；

方案缺点：

无法支持多站点跨站登录，即Web端服务器只能给一个业务提供扫码登录功能；

由于直接返回了Token，安全风险等级较高；

3.2.2授权Ticket

Web端服务器在扫码完成后，返回的是一个授权Ticket（也可以直接返回带Ticket的授权url,便于Web端直接跳转），之后需要Web端带着这个Ticket调用目标服务器的接口进行身份的验证同步，如图所示：

点击加载图片

方案优点：

没有直接传递Token，安全性更好；

可以支持多站点跨站登录身份信息的同步，适用于服务于多站点的扫码登录服务；

方案缺点：

实现逻辑较为复杂，需要维护完整的授权Ticket生成、校验以及失效逻辑；

3.2.3方案选择

4安全防护

前面提到，扫码登录的本质是通过扫码手段安全稳定地同步用户信息。那么我们可以通过哪些手段提高同步过程中的安全性？

4.1定时过期

每个二维码都有一个唯一的uuid与之对应，为了防止恶意人员通过接口遍历查询以获取之前已经被扫的二维码信息，数据不能永久存储于db中，需要完成扫码后从db删除或者定期过期清除。

4.2UUID不可遍历

简单的方案是将自增ID和一个固定salt进行md5之后生成一个字符串作为uuid；也可以通过UUID.randomUUID生成一个随机字符串。当然，还可以采用对称加密的方式存储一些加密信息。

4.3签名验证

这个方式关键点在于将uuid和请求中的Cookie或参数信息经过哈希算法得到一个signature值，此时即使有人破解了uuid的生成规则，只能生成uuid，但是无法获知对应uuid生成时对应的Web端状态(Cookie)，因此破解了uuid后也无法获取对应signature值，也就无法获取二维码状态。

4.4合理限流

一般是在获取二维码阶段对来源IP进行访问的限制。

当然扫描二维码阶段也可以做限流，但是如果采用是定时轮询方案，由于访问次数太多，无法做到精确识别和控制，可操作性不强；而如果采用的是阻塞等待方案，也能进行限流，但是如果已经采用了上面参数签名验证，则可以把恶意用户都收口在获取二维码阶段，在这个阶段限流的意义不大。

5总结

其实每个方案都有其适用的场景和阶段，没有严格意义上的孰优孰劣，这个从各互联网公司的选择中也能看出，而要基于自身的需要选择最合适的方案，切忌盲目选择最复杂的方案。