二维码登录

二维码登录

二维码登录的本质是登录。而登录的本质在于向服务端证明自己的身份。

也就是说，PC端向服务端证明自己的身份是核心思想所在。

我们逆向拆解一下，想象一下二维码登录的业务流程（简化版）：

• PC从服务器拿到一个二维码，显示在桌面上
• 用户掏出手机，扫码，并点击确认登陆
• PC登录成功。

从中可以看出，实际上是手机告诉了服务端，PC端的身份是可信的。服务端信任手机端（因为手机端已经登录，请求携带token让服务端信任手机发来的请求），所以同样信任手机端给PC端的保证。

大概思路懂了，那么还有以下疑点：

PC从服务端拿到的二维码是什么？有什么作用？

这个二维码实际上就是《xxxPC端的身份确认担保表》，担保人就是手机端，这个“表”中包含了服务端的URL，手机就知道这个表该交给谁了。这个二维码是独一份的，服务端只会给一个PC发送一次，还会过期，防止了错误登录的发生。服务端收到来自手机的验证后，服务端的状态变为登陆成功。那么问题来了：

服务端无法主动告知PC扫码登陆成功，怎么办？

方法很多，可以展开想象，建立websocket连接，PC向服务端轮询，或者是长连接（客户端发送请求后先阻塞，直到扫码登陆成功才返回请求），这些都能实现真/伪 服务端向客户端主动告知的效果。如某B开头的视频网站使用的就是每秒一次的轮询。这次PC端将收到登陆成功的消息，并获得来自服务端发放的token。

既然收到来自服务端发放的token，那就有被劫持的可能！

用户A从服务端收到了扫码登陆的二维码，然后在不知情的情况下泄露了这个二维码，紧接着A扫描了二维码点击登录，黑客在自己的电脑上利用这个二维码将自己伪造成A，向服务器询问登录是否成功，然后就可以劫持到这个token了！所以需要做好措施，防止这种情况的发生：

• 二维码绑定会话信息，也就是sessionId，那么黑客必须同时窃取sessionId和二维码才行，提高了难度
• 除了绑定sessionId，也可以绑定其他与PC标识符有关的，比如设备码，ip地址等等
• 服务端检测该二维码的轮询频率是否异常（正常用户和黑客同时轮询，那么频率肯定不正常）