用户扫码登录设计

扫码登录是在手机普及之后才推出的一种安全又便捷的登录方式，前提是扫码应用（手机App）与需要扫码登录的系统必须使用同一

套用户体系。所以，使用微信扫码登录第三方网站本质上是借助了OAuth 2.0协议中的授权码模式。第三方网站其实借用了微信的用户信息，与自己的用户信息进行了绑定。那么，如果不使用微信而使用自己的App是如何完成扫码登录的呢？

扫码登录流程如图4-50所示，总体分为以下3个步骤。

（1）      浏览器展示登录二维码，并提示用户使用指定App进行扫码登录。

（2）      用户使用指定App扫描浏览器中的二维码。

（3）      浏览器跳转到登录成功页面（大多数跳转到系统首页）。

图4-50 扫码登录流程

扫码登录是由多个系统协作完成的，包括浏览器、二维码服务、App、App后端服务和网站系统服务。扫码登录实现流程如图4-51所示。

（1）     第1.1步：打开系统的二维码登录页面，调用网站系统服务去获取二维码。

（2）     第1.2步：网站系统服务先生成唯一的业务流水号，并保存在数据库中，同时记录登录状态为未登录。

（3）     第1.3步：网站系统服务去请求二维码服务，并携带业务流水号、登录地址信息等。二维码服务接收到请求后生成二维码的唯一标识，并生成含有指定授权登录的URL信息的二维码图片。

例如，http://www.yinhongliang.com/auth?

qcode=1wdi03020134&busid=a23axd4，其中qcode为二维码的唯一标识，busid为业务流水号。

（4）     第1.4步：二维码服务将qcode和Base64图片返回给网站系统服务。

（5）     第1.5步：网站系统服务记录qcode，并与busid形成一对一的绑定关系。

（6）     第1.6~1.8步：浏览器页面再使用qcode不断地去轮询二维码服务，查询当前二维码的状态是什么。如果状态为已扫描，则页面显示二维码已扫描；如果状态为已失效，则页面提示二维码已失效，如图4-52所示。

（7）     第2.1~2.7步：用户使用指定的App扫描浏览器上的二维码，手机识别出二维码中的URL信息，然后跳转到指定的授权页面。此时

App异步通知二维码服务，此二维码已经被正确扫描并识别。二维码服务收到通知后，将二维码的状态更新为使用中的状态。因此，当浏览器页面再次轮询状态时，二维码就会显示为“二维码已扫描，请在手机上完成操作”，如图4-52所示。

图4-51 扫码登录实现流程

图4-52 二维码的状态变化

如果此时用户已经登录过App，则直接提示用户是否授权登录××系统，如图4-53所示。

如果此时用户并没有登录过App，则先要求用户录入用户名和密码完成登录流程，再做授权，如图4-54所示。

图4-53 已登录状态下的App授权

图4-54 未登录状态下的App授权

用户完成App端授权后，会通知到App后端服务，授权通过。

（8）     第3.1~3.4步：App后端服务接收到用户同意授权的通知后，会携带当前用户的唯一标识、二维码的唯一标识qcode、业务流水号 busid，再去通知网站系统服务。首先网站系统服务要完成该用户的登录动作，生成对应的Session 或Token信息；然后更新对应业务流水号的状态为登录成功；最后携带二维码的唯一标识qcode去通知二维码服务，将二维码的状态更新为已使用状态。此时浏览器再刷新二维码的状态，则将显示为“此二维码已经使用”。

（9）     第4.1~4.3步：浏览器使用业务流水号busid去轮询网站系统服务，查询登录状态，如果状态为登录成功，则直接跳转到用户首页，完成整个扫码登录流程。

二维码服务的数据存储结构主要如表4-14所示。

表4-14 二维码信息存储结构

业务系统服务的数据存储结构主要如表4-15所示。

表4-15 二维码登录信息存储结构

一个看似简单的扫码登录，其实还是具有一定复杂性的，尤其是浏览器存在对二维码的状态轮询，以及对业务流水号的状态轮询两个动作，会造成请求十分频繁，因此一定要尽量降低二维码的有效时长，一旦二维码失效就立即停止轮询，等待用户刷新二维码再继续。如果把二维码的有效时长设置为1小时，则用户只要停留在该页面上，就会持续地进行轮询，耗费服务器资源。

更好的一种方式是将轮询机制更换为通知机制。例如，使用

WebSocket技术，在二维码的状态发生变化或登录的状态发生变化时，由网站系统服务主动通知浏览器，从而完成二维码展示的更新，以及系统首页的自动跳转。