如何实现Web端扫码登陆
7.1 前提：在移动客户端上认证用户身份
这也就是需要先在一个移动设备上进行登陆，一般是专用应用而不能是移动端的浏览器页面。
7.2 扫码登陆流程
在阅读这部分内容前请确保你已经完全掌握认证的含义，关于认证已在文章开篇有详细的讲解。
7.2.1 认证前从客户端发起请求：
一旦前端对于从服务端发来的 Key ，便对其进行编码成一个二维码，如 qrCode，用户用户在移动端进行扫码：
扫码登陆：这是笔者为了说明而做的一个模拟扫码页面
安全起见，二维码是有有效期的，可以手动设置一个有效期，也可以给定一个刷新按钮来从服务器更新二维码信息并在客户端中重新渲染。
7.2.2 用户在移动设备扫码
这一阶段中：
- 对于 Web客户端 而言，客户端拿着自己从服务端获取的Key向服务端发起轮询已了解自己在移动设备上是否完成身份认证。
- 对于 移动端 而言，当移动设备上进行扫码后，移动端便获取了Web客户端从服务器获取的Key。为了确保安全，移动端不应急于提交数据而应先向移动设备操作者确认登陆意图，对于安全较高的应用情景如银行帐户的登陆等，还需要做进一步的确认如人脸验证、语音验证、短信验证等等。验证完成后，将从PC客户端扫码获取的key与移动端自己存储的身份信息（有可能也是一个令牌之类的签名工具）发送的服务端。
7.2.3 服务端响应客户端的轮询
对于 服务端而言，它时刻监听着来自多个移动端和Web客户端发过来的请求（可能有多个用户同时在进行认证操作）。 一旦监听到了移动端传来的key与用户身份签名，意味着之前发给Web客户端用户生成二维码的Key被移动端扫描登陆中，这时需要响应此Key对应的客户端的轮询。可想而知为了额能确定相应的到底是哪一个Web客户端的轮询，这就要求服务端的Key必须是全局唯一的。
7.2.4 Web客户端完成登陆
当客户端在某次轮询后得到了签名工具（令牌 token）后，意味着以后可以使用该令牌对需要回传服务器的数据进行身份签名。这时可以提示用户“扫码登陆成功”，并跳转到相关的页面。但是需要注意的是，处于安全考虑仍不建议将与用户相关的重要数据存储在 token 中，因为这样容易导致 token 被破解带来的用户信息泄露。此处妥当的做法仍然是，将 token 用作某个时间端内在服务端标识某特定用户的键，但其中所有与用户相关的信息（值）仍然是存储在服务端的。
