手机客户端扫描登录..确认登录
服务端生成登录..，绑定..与pc客户端处理..轮询处理手机端扫描..处理手机端确认..登录处理pc端自动登录
实现
PC端如何自动登录
这个问题相当于同一个帐号多设备同时登录的问题
在..被具有登录态的app端扫描确认之后，PC端如何完成自动登录。有如下几个方案：session拷贝
其实就是在原来基于账号密码的登录鉴权逻辑基础上，新增支持无需账号密码的登录。也就相当于绕过了基于用户名密码，内部重新设置了一个登录态
如果是基于session的鉴权，相当于基于原有的一个已经鉴权的session，，拷贝信息到另外一个新的session中，在server端关联复用已有token
如果是基于token的鉴权，一种方案就是复用token，让pc端也复用手机app端的token，这样的好处是原来基于token的鉴权逻辑都不用改仿照oauth授权颁发新token
整个过程其实有点像oauth，pc端是client，server端是资源和认证中心，手机端是具有登录态的用户。手机端扫描..，然后用户确认授权，server端给pc端颁发token，然后pc端就可以访问server端的资源了。这种就在原来的认证基础上支持另外一类oauth的token校验，貌似有点复杂
另外一个变形是新颁发token，但跟app端的token有个关联映射，最终鉴权的时候还去找原来授权的token去鉴权，这样的好处是原来的token失效，经过它授权的token也失效
..过期
一种是基于redis来做过期，一种是使用数据库，但是设置expired time来判断
安全问题
QRLJacking全称Quick Response Code Login Jacking，是session劫持的一种。
原理
具体是怎么劫持的呢，假设攻击者将web登录..伪装为公众号..，让用户去扫描，用户一不小心点击确认，攻击者的就可以登录用户的web系统，或者利用那个token/session去盗取用户的相关信息或做相关操作。
防范
..超时机制
..增加超时机制之后，会增加攻击者攻击的难度，不过攻击者也可能利用脚本去自动刷新..确认机制
..扫描一定要有这个确认的页面，明确告知用户要做的操作，假设没有确认这个环节，那么是极其容易上当的。另外，..扫描确认之后，再往用户app或手机等发送登录提醒的通知，告知如果不是本人登录的，则建议用户立即修改密码Sound-based Authentication
确认阶段改为双边语音确认，而不是简单的用户点击确认按钮。语音是根据用户id、..id等加密生成，在app端播放，然后pc端语音识别之后才能完成整个登录过程。这个可以有效防止远程攻击。同样的思路，改语音为one time password也行，增加了确认过程的复杂度，也就增加了攻击的难度。
小结
..扫描登录是个挺潮流的功能，这要求既有系统增加改造，也要求针对这种形式的登录带来潜在的攻击进行安全防范。
