扫码登录流程及原理

一、本质

1、二维码

二维码实质上就是字符串的另一种表现形式，它存储的本身就是字符串信息，可以包括但不限于文本、网址、文件、图片等等一系列直接或间接的字符串信息。我们可以看一个生成二维码的网址草料二维码，可以扫描出对应的字符串信息

2、二维码登录

与别的登录方式相同，二维码登录实际上也是做了两件事：告诉系统我是谁、向系统证明我是谁。例如账号密码登录，账号负责告诉系统我是xxx，密码负责证明我是xxx。那么，二维码是如何做到这两件事的呢？

1. 告诉系统我是谁：首先要明确，二维码登录是已登录的APP端去扫WEB端的二维码，那么，既然APP端已登陆，那么肯定能拿到用户信息，这样就能告诉系统我是谁
2. 向系统证明我是谁：那么扫码过程中是把密码传给WEB端了吗？肯定不是的，这样非常不安全，实际上，APP端我们已经登录了，这就说明当前账号通过了系统认证，我们只需要扫码是这个手机且是这个账号操作的，就能间接证明我谁。

3、系统认证机制

首先我们需要明确的是，APP端不会存储登录密码（注意区分手机端自己的密码保存和APP的密码保存），其次在APP端登录，第一次输入密码登录成功之后，只要不退出账号或者登录信息过期，即使我们杀死后台，再次点开app之后，也是自动登录的，这里面是有一套token认证机制，如下：

1. 账号密码登录时，将设备信息给到了服务端
2. 服务端校验密码成功，服务端将设备信息和账号信息进行绑定，存储在一起，包含了设备id，账号id，设备类型等等
3. 服务端生成一个token映射上面的信息，返回客户端
4. 客户端拿到服务端的token之后进行一个本地保存，之后每次请求都带上这个token和设备信息来证明身份
5. 服务端拿到token之后查询绑定的设备信息，与传入的设备信息进行比对，成功之后返回请求响应信息

可以看到上面的流程中，客户端并没有保存密码信息，而是保存了token，那么这样会有安全问题吗？token里面绑定了设备信息，因此只要我们的设备信息不泄露，即使获取了token，用别的设备也是不能成功访问的

二、原理

1、整体流程

1. APP端登录状态，PC端展示一个待扫描的二维码
2. APP端扫描二维码，扫描后会提示“确认登录”
3. APP端点击确认登录之后，PC端登录成功

可以看到，在整个过程中PC端是一直在轮询二维码状态的，二维码主要经历了三个状态转变

1. 每个二维码有它自己唯一的id，生成二维码时这个id也生成了，还绑定了PC端的设备信息
2. APP端扫面二维码后，进入待确认状态，此时已经将账号信息传给了PC端，因此二维码还绑定了账号信息
3. 确认之后，二维码转为已确认，此事已经证明了我是谁，因此服务端会生成PC端的一个token用来做后续请求

2、生成二维码

1. PC端请求服务端生成二维码，并将自己的设备信息传递过去
2. 服务端生成二维码id，并将PC端的设备信息与id进行绑定
3. 返回二维码id
4. PC端根据二维码id（这就相当于生成二维码的字符串信息）绘制二维码并展示
5. 轮询二维码的状态

3、扫描二维码

这里需要注意，轮询二维码是覆盖整个扫码过程的，不要被图误导（一点点小失误）

1. APP端扫描二维码，获取到二维码id
2. 调用服务端接口，传递二维码id及APP端的用户信息
3. 服务端将用户信息与二维码id绑定，生成一个临时token返回APP端
4. PC端轮询到二维码状态改变，在页面将二维码状态更改为已扫描

这里返回的是临时token，其实和token一样，只不过有一个有效期，因为扫码动作并不是一个永久的操作，每次都要重新扫码，所以返回临时token

4、确认登录

1. APP端确认登录，携带临时token请求服务端，告诉它我确认登录了
2. 服务端校验临时token通过，根据二维码id绑定的设备信息与用户信息，生成PC端的token，改变二维码为已确认状态
3. PC端轮询到二维码状态改变，并且拿到了服务端返回的token
4. 登陆成功，携带着token做后续业务请求