二维码扫码登录原理

简介

二维码扫码登录这个操作，在我们的日常生活和工作中频频出现。

这种操作主要发生于：在手机设备已经登录的情况下，需要在电脑PC端应用或者网页应用也登录，这时，如果该应用支持扫码登录，我们就可以用手机端的应用来扫描PC端生成的一个二维码，进而进行登录。如下图所示：

比如我们每个人几乎都会接触过的：

微信扫码登录、QQ扫码登录、网易云音乐扫码登录、百度网盘扫码登录等等。

首先，我们来简单描述一下扫码登录这个流程，用微信登录进行举例：

假设：手机端已经登录了微信，这时需要在PC端登录

（1）PC端生成一个二维码，等待扫描

（2）使用手机端微信的扫一扫功能扫码二维码

（3）手机端解析二维码并弹出确认登录弹窗，此时PC端的二维码状态显示为：已扫描，等待确认

(4) 手机端点击确认登录，这时PC端的微信完成登录

分析

以上几个大体步骤就是我们进行扫码登录的一个基本流程。那么，我们要如何去设计这么一个功能呢？

在开始设计之前，我们需要思考明白一下几个关键点：

在手机端进行确认登录的时候，为什么PC端就能直接登录？
在扫码登录整个过程中，手机端和PC端是否需要有数据传输（如用户ID或者用户名+密码）？
如何保证扫码登录的过程是安全的，非信息暴露泄漏的？
PC端是如何检测到二维码的状态的（已扫描、已取消、已确认等）？

首先，前两个问题我们一起综合分析：

在扫码登录过程中，需要明确的是，手机端和PC端是肯定有数据交互的，不然PC端是无法登录得了的。那双端交互的这个数据会是用户ID或者用户名密码吗？

先排除后者，传输用户名密码最大的缺点就是用户敏感信息可能会造成泄漏，其次是，我们平常输入用户名密码登录，是客户端传输数据到服务器，然后在服务器进行校验并存储。但是这里如果传输用户名密码，就是从服务器传到PC客户端，然后PC客户端拿到后又原样不变地发送给服务器进行登录，这很明显逻辑奇怪并且流程冗余，会造成一定的服务器资源浪费；

那会是传输用户ID吗？在理解不传输用户名密码的第二个原因后，那么也很容易明白，显然也不能或者不会传输用户ID。PC客户端虽然可以使用服务器返回的用户ID进行用户信息状态查询、同步等操作，但是直接拿用户ID进行一个“登录操作”，相当于跳过了token机制，那么以后在PC端的登录状态就没有过时的说法了，用户ID是一直不变的，只要客户端保存着这个ID，就可已拿这个ID进行登录验证，这显然不合理也不安全的。因此，也不可能是传输用户的ID。

那到底是什么数据在进行交互呢？

答案是：一种仅用于扫码登录的临时token令牌数据

PC端在选择使用二维码登录的时候，服务器会生成一个二维码，并且这个二维码绑定着一个ID（二维码ID），当手机设备扫描二维码后，会解析二维码并拿到这个ID；然后当手机端点击确认登录后，手机端会带着这个ID，以及手机端上已经登录了的用户身份信息token，一起发送给服务器，服务器接收到后，新生成一个专门给PC端使用且绑定了用户身份的token，然后返回给PC端，这样PC端就相当于登录了，之后PC端的用户检验就是用这个token进行。当然，这里已经忽略了很多细节过程，下文会更加详细地流程描述。

其实这里，已经回答了第三个问题：如何保证扫码登录的过程是安全的，非信息暴露泄漏的？

在整个扫码登录过程中，手机端与PC端涉及的数据交互，仅仅是由服务器管理控制的一个二维码ID、手机端上的用户身份token（有时效性）、服务器新生成给PC端的用户身份token（有时效性），没有敏感信息交互，也就不存在敏感信息的泄漏；服务器给PC端生成一个新的token，从另一个角度上看，就跟用户输入用户名密码登录的本质是一样的，都是基于带时效性的token校验机制，只不过扫码登录的方式少了输入用户名密码这一个步骤。因此，这样的一个扫码登录流程是安全的。

最后一个问题，PC端是如何检测到二维码的状态的呢？

其实这里应该很容易就能想到了，无非两种：socket和轮询

socket方式：

PC端保持着与服务器的长连接，当手机端扫描二维码后，带着解析得到的二维码ID第一次发送给服务器，当服务器收到这个请求后，代表用户已经扫描了二维码，这时服务器就可以通过socket告知PC端二维码已被扫描，等待确认；之后手机端不论是取消登录还是确认登录，都会相应的请求服务器，服务器收到请求会根据相应的逻辑处理，进而通知PC端更新相应的状态，流程图如下：

轮询方式：

轮询方式即在PC端创建一个定时器，每隔一段时间请求服务器查询状态的更新情况，然后更新网页的显示信息。当时这个定时器得控制好启动时机和生命周期，因为PC端的二维码有可能一直没有被扫描，或者扫描之后没有下一步操作了，这时，如果没有控制好这个定时器，PC端就会一直地请求服务器查询，造成资源浪费和一定的性能损耗。

轮询的流程如下图所示：