二维码认证原理

前言

传统的扫码登录web页面，一般需要先登录手机APP，然后再扫码确认，使其完成自动登录。

在这里手机APP可以分为两大类，一个是自有的APP，一个是第三方的APP。

如果是接入第三方APP扫码认证，就按第三方提供的标准来接入，如微信的二维码接入。

 

二维码认证场景

1. 手机APP登录状态下，扫码登录WEB页面
2. 用户使用密码登录后，再使用手机APP登录状态下扫码登录WEB页面（双因素认证）

 

原理流程

前提：手机app已经登录，自带有登录的凭证，然后要扫描登录pc端的系统

以下的所有步骤，都基于这个前提

 

1. 当用户使用浏览器输入需要访问的地址，这个时候提示未登录，跳转至登录页面。
2. 前端请求后台服务端获取二维码，这个时候后台服务端生成一个UUID，并且将这个UUID与前端请求中带有的sessionid，进行关联，设置有效期，设置二维码状态为：NEW，并且存储起来。（可以是缓存redis，也可以是数据库）。
3. 前端获取服务端响应的二维码UUID，根据前端js插件生成一个二维码，并且轮询向服务端进行请求该二维码的状态。直到二维码状态，为已过期，或者确认登录为止。
4.  就在此时，用户拿出了手机，打开APP扫描二维码，APP读取二维码的UUID，并且请求后端服务器，检测二维码有效期（过期就将二维码更新为过期EXPIRED），如果没过期就将二维码状态更新为已扫描状态（SCANED），手机弹出确认登录按钮

5. 用户点击确认，APP再次请求后端服务器，将二维码更新为已确认状态（CONFIRMED），同时存储用户的基本信息：如用户名与sessionID和二维码的UUID相关联，如果用户拒绝了，就发送请求后端服务器，将二维码更新为拒绝状态（REFUSED）。

6. 在第3步中有说到，由于前端js不断在轮询二维码的状态，此时二维码的状态为已确认状态（CONFIRMED），前端那么就会向后台服务器发送自动登录请求，携带参数有二维码的UUID和请求头中的sessionID（请求中会默认带上sessionID）。

7. 后端获取到前端请求，拿着sessionID+二维码UUID，判断二维码UUID是否过期，如果已过期返回页面重新扫码，如果未过期就获取到用户名，生成会话。

8. 在会话生成后，删除二维码UUID和sessionID关系这条数据，重定向到登录后的页面，完成自动登录。

 

注意：前端二维码获取的状态有：新二维码，被扫描，已确认，已拒绝，已过期。                    NEW,SCANED,CONFIRMED,REFUSED,EXPIRED

状态为：拒绝、已过期时，停止轮询更新，要求重新刷新二维码。

 

写的不太好，欢迎各位留言讨论，亲喷。

 

 

参考文献：https://segmentfault.com/a/1190000012446715