相关技巧

关注公众号 jb51net

关闭
首页 > 网络编程 > 相关技巧 > 扫码登录的原理和实现

Web端扫码登录的原理和实现讲解

作者:程序猿周周

这篇文章主要介绍了Web端扫码登录的原理和实现,扫码登录相比较传统的密码登录更加快捷和安全,今天我们就来讲讲原理与实现,主要分为几种不同的解决方案,需要的朋友可以参考下

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

方案优点:

方案缺点:

3.1.2 轮询

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

方案优点:

方案缺点:

3.1.3 长轮询

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

方案优点:

方案缺点:

3.1.4 方案选择

三种方案各有优缺点,应该结合业务进行选择。

先以微信公众平台为例,进入其扫码登录页,就会发现密密麻麻的调用获取扫码状态请求过程,很明显是采用了轮询方案。

在这里插入图片描述

再看看其他厂家选择:

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

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

3.2 获取登录信息

当用户扫码登录后,Web 服务器如何将用户信息(如 Token)同步给 Web 端。

3.2.1 返回 Token

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

方案优点:

方案缺点:

3.2.2 授权 Ticket

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

在这里插入图片描述

方案优点:

方案缺点:

3.2.3 方案选择

平台方案
微信开放平台授权Ticket
微信公众平台Token
京东授权Ticket
淘宝&&天猫授权Ticket
百度授权Ticket
B 站授权Ticket
快手授权Ticket

经过调研发现,在国内互联网各大厂商中返回授权 Ticket 的方案被较多采用,这也由于各家旗下拥有众多 PC Web 站,直接返回 Token 的方案无法多站点的登录信息同步,而上面表格中亦有一个另类——微信公众平台,大概与其产品独立性有关。

4 安全防护

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

4.1 定时过期

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

4.2 UUID不可遍历

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

4.3 签名验证

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

4.4 合理限流

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

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

5 总结

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

到此这篇关于Web端扫码登录的原理和实现讲解的文章就介绍到这了,更多相关扫码登录的原理和实现内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文