一文搞懂主流的扫码登录技术原理
前言
随着wx的普及对开发同学来说一些业务场景会使用到“扫码登录”功能，特别是PC网页端，在此之前没有这方面的开发经历，所以接到这个需求的时候还是有点慌的，最终通过查阅网上的资料以及老大的指导下实现了这个功能，目前已经投入使用，实现之后还是蛮兴奋的。特此记录一下实现的过程。
原理解析
扫码登陆的实现需要手机端的服务器和Web端的服务器配合实现。大致分为以下几步：
step1：网页端请求登陆二维码
要实现网页版的扫码登陆，用户必须先要请求一个登陆的二维码。Web端的服务器收到用户申请登陆二维码的请求后，会随机生成一个uuid（这个uuid作为页面的唯一标识符），并且会将这个uuid当做一个键值对的key存入后台Redis。存入Redis的这个键值对的value是什么我们待会再说。
需要注意的是存入Redis的键值对必须设置一个过期时间，不然的话拿着这个uuid登陆一次后就一直处于登陆状态了。
当浏览器端拿到Web服务端返回的二维码信息后，解析其中的uuid，并拿这个uuid不断去后台轮询是否已经登陆成功。如果后台已经登陆成功，Web端就自动跳转到登陆成功页面。不然的话会一直轮询，直到二维码失效（这里我们发现给二维码设置有效时间真的很有必要，如果二维码没有有效时间的话，会不断的轮询后台，给后台造成很大的压力）。
那么上面的关键点是Web端服务器是怎么判断用户是否已经扫码登陆成功过的呢？ 请看下面的步骤。
step2：手机端将用户id存入Redis
用户请求到二维码后，就开始拿出手机，打开相应的App扫描二维码。扫描过程中手机会将uuid和手机端登陆后获得的token信息一起提交到手机端服务器。
手机端服务器会先拿token信息判断这个用户是否合法，是否已经正常登陆。如果判断已经正常登陆，那么会将这个用户的userId和提交过来的uuid当做一个键值对（uudi-userId）存入Redis。这边回答了步骤一种留下的问题。
简单来讲手机端做的工作就这么多。让我们继续回到Web端。
step3：web端轮询成功
步骤一中讲到：二维码登陆页会不停的轮询是否登陆成功。这边的依据就是Redis中存在uuid-userId键值对。如果这个键值对已经存在，说明手机端已经扫码登陆过。
Web端服务器一旦判断到手机端已经扫码登陆过，就可以拿着userId进行登陆。并将必要的用户信息和token信息返回Web前端。至此Web端登陆成功。
简单总结
本文记录了一个扫码登陆的简单版本，但是也能描述扫码登陆的大致原理。实际开发过程中应该还是有许多细节需要考虑。比如安全问题等。具体的还是需要我们进行实战了。
欢迎大家一起讨论~
作者： 写代码的木公
出处：https://www.cnblogs.com/54chensongxia/p/12530268.html
一文搞懂主流的扫码登录技术原理
转自：imtech
https://my.oschina.net/u/4231722/blog/3154805
1、引言
扫码登录这个功能，最早应该是微信的PC端开始搞，虽然有点反人类的功能（不扫码也没别的方式登录），但不得不说还是很酷的。
下面这张图，不管是IM开发者还是普通用户，应该很熟悉：
于是，搞IM产品的老板和产品经理们从此又多了一个要抛给程序员们的需求——“为什么微信有扫一扫登录，而我们的没有？”。
好吧，每次只要是微信有的功能，IM程序员们想甩锅，难度就有点大了，毕竟老板们都都会想当然认为，微信有的“我”的IM产品里也得有。
既然无法回避，那就只能老老实实搞懂技术原理，然后自已使劲撸吧。
本文将简要的介绍扫码登录功能的技术实现逻辑，并实际结合淘宝、微信的扫码登录功能，学习和研究大厂主流应用的技术实现思路。
2、基本技术原理
2.1 扫码登录功能到底是什么样的？
首先介绍下什么是扫码登录。现在大部分同学手机上都装有微信、qq和淘宝这一类的软件。而这些app都有他们相对应的网页端。为了让用户在使用他们的网页时登录更加方便和安全，使用手机扫一扫就可以登录的服务，就显得自然而然了。
几个主流大厂应用扫码登录时的界面效果如下：
有很多小伙伴可能会感到很神奇，网页上只是显示了个二维码，它怎么就知道是哪个手机扫到了二维码，并且进行登录的呢？而且，登录完成以后，还能直接把用户信息显示给用户，真的是很神奇啊。
2.2 扫码登录功能的完整技术逻辑
1）网页端与服务器的配合逻辑：
接下来就是对于这个服务的详细实现。
首先用户打开网站的登录页面的时候，向浏览器的服务器发送获取登录二维码的请求。服务器收到请求后，随机生成一个uuid，将这个id作为key值存入redis服务器，同时设置一个过期时间，再过期后，用户登录二维码需要进行刷新重新获取。
同时，将这个key值和本公司的验证字符串合在一起，通过二维码生成接口，生成一个二维码的图片（二维码生成，网上有很多现成的接口和源码，这里不再介绍）。然后，将二维码图片和uuid一起返回给用户浏览器。
浏览器拿到二维码和uuid后，会每隔一秒向浏览器发送一次，登录是否成功的请求。请求中携带有uuid作为当前页面的标识符。这里有的同学就会奇怪了，服务器只存了个uuid在redis中作为key值，怎么会有用户的id信息呢？
这里确实会有用户的id信息，这个id信息是由手机服务器存入redis中的。具体请继续阅读“手机端与服务器的配合逻辑”。
2）手机端与服务器的配合逻辑：
话说，浏览器拿到二维码后，将二维码展示到网页上，并给用户一个提示：请掏出您的手机，打开扫一扫进行登录。
用户拿出手机扫描二维码，就可以得到一个验证信息和一个uuid（扫描二维码获取字符串的功能在网上同样有很多demo，这里就不详细介绍了）。
由于手机端已经进行过了登录，在访问手机端的服务器的时候，参数中都会携带一个用户的token，手机端服务器可以从中解析到用户的userId（这里从token中取值而不是手机端直接传userid是为了安全，直接传userid可能会被截获和修改，token是加密的，被修改的风险会小很多）。手机端将解析到的数据和用户token一起作为参数，向服务器发送验证登录请求（这里的服务器是手机服务器，手机端的服务器跟网页端服务器不是同一台服务器）。
服务器收到请求后，首先对比参数中的验证信息，确定是否为用户登录请求接口。如果是，返回一个确认信息给手机端。
手机端收到返回后，将登录确认框显示给用户（防止用户误操作，同时使登录更加人性化）。用户确认是进行的登录操作后，手机再次发送请求。服务器拿到uuId和userId后，将用户的userid作为value值存入redis中以uuid作为key的键值对中。
3）登录成功时的逻辑：
然后，浏览器再次发送请求的时候，浏览器端的服务器就可以得到一个用户Id，并调用登录的方法，生成一个浏览器端的token，再浏览器再次发送请求的时候，将用户信息返回给浏览器，登录成功。这里存储用户id而不是直接存储用户信息是因为，手机端的用户信息，不一定是和浏览器端的用户信息完全一致。
4）详细的技术原理总结如下图所示：
3、淘宝的扫码登录技术实现
本节我们以淘宝的扫码登录为例，来实际研究分析一下淘宝的扫码登录实现逻辑。
登录界面 https://login.taobao.com/member/login.jhtml 传回来的参数为：
然后请求(GET)报文是这样的:
https://qrlogin.taobao.com/qrcodelogin/qrcodeLoginCheck.do?lgToken=2c3b4d53ef0513787bf4ce711ea5ba53&defaulturl=&_ksTS=1540106757739_2804&callback=jsonp2805
关键的就是lgToken，是网页的唯一ID，当打开了二维码登录的时候，网页在轮询(应该是长轮询long polling)调用接口去请求服务器。
如果没有扫码，返回的为：
如果扫了的话则会返回：
{ "code": "10001", "message": "mobile scan QRCode success", "success": true}
长时间没有扫码的话，网页端会停止轮询，二维码失效！
当手机端确认登录后，接口返回的是：
{ "code": "10006", "success": true, "url": "https://login.taobao.com/member/loginByIm.do?uid=cntaobaoxxx&token=ff82fc0d1d395a33d3b38ec5a4981336&time=1530179143250&asker=qrcodelogin&ask_version=1.0.0&defaulturl=https://www.taobao.com&webpas=0b7aed2d43f01825183e4a49c6cae47d1479929926"}
表示登录成功，当然手机端与服务端在点击”确认登录”之间的交互可能就是这样：网页端生成的lgToken去请求服务端，服务端记住了这个lgToken并认为登录了，当网页端再次轮询请求接口时，就返回真正的登录态Token，网页端此时就可以凭着这个Token来登录了。
详细的技术逻辑如下图所示：
4、微信的扫码登录技术实现
4.1 技术原理流程图
微信的网页版访问地址是：https://wx.qq.com/，有兴趣也可以自行深入研究。
4.2 实际的技术实现逻辑
1）获取唯一的uuid, 以及包含uid信息的二维码：
// 获取uuidgetUUID: function() { vare = t.defer(); returnwindow.QRLogin = {}, $.ajax({ url: i.API_jsLogin, dataType: "script" }).done(function() { 200 == window.QRLogin.code ? e.resolve(window.QRLogin.uuid) : e.reject(window.QRLogin.code) }).fail(function() { e.reject() }), e.promise}
2）浏览器轮询服务器，获取扫码状态：
// 查看扫码状态checkLogin: function(e, a) { varn = t.defer() , a = a || 0; returnwindow.code = 0, window.checkLoginPromise = $.ajax({ url: i.API_login + "?loginicon=true&uuid="+ e + "&tip="+ a + "&r="+ ~newDate, dataType: "script", timeout: 35e3 }).done(function() { newRegExp("/"+ location.host + "/"); if(window.redirect_uri && window.redirect_uri.indexOf("/"+ location.host + "/") < 0) returnvoid (location.href = window.redirect_uri); vare = { code: window.code, redirect_uri: window.redirect_uri, userAvatar: window.userAvatar }; n.resolve(e) }).fail(function() { n.reject() }), n.promise}
3）根据服务器返回的扫码状态，进行相应的操作：
408 扫码超时：如果手机没有扫码或没有授权登录，服务器会阻塞约25s，然后返回状态码 408 -> 前端继续轮询
400 二维码失效：大约5分钟的时间内不扫码，二维码失效
201 已扫码：如果手机已经扫码，服务器立即返回状态码和用户的基本信息 （window.code=201,window.code.userAvator=”…”），-> 前端继续轮询
200 已授权：如果手机点击了确认登录，服务器返回200及token -> 前端停止轮询, 获取到token，重定向到目标页
具体的代码示例如下：
// 根据服务器返回的扫码状态，进行相应的操作functiono(c) { switch(c.code) { case200: t.newLoginPage(c.redirect_uri).then(function(t) { varo = t.match(/<ret>(.*)</ret>/) , r = t.match(/<script>(.*)</script>/) , c = t.match(/<skey>(.*)</skey>/) , s = t.match(/<wxsid>(.*)</wxsid>/) , l = t.match(/<wxuin>(.*)</wxuin>/) , d = t.match(/<pass_ticket>(.*)</pass_ticket>/) , f = t.match(/<message>(.*)</message>/) , u = t.match(/<redirecturl>(.*)</redirecturl>/); returnu ? void (window.location.href = u[1]) : o && "0"!= o[1] ? (alert(f && f[1] || "登录失败"), i.report(i.AUTH_FAIL_COUNT, 1), void location.reload()) : (e.$emit("newLoginPage", { Ret: o && o[1], SKey: c && c[1], Sid: s && s[1], Uin: l && l[1], Passticket: d && d[1], Code: r }), void (a.getCookie("webwx_data_ticket") || n.report(n.ReportType.cookieError, { text: "webwx_data_ticket 票据丢失", cookie: document.cookie }))) }); break; case201: e.isScan = !0, n.report(n.ReportType.timing, { timing: { scan: Date.now() } }), t.checkLogin(e.uuid).then(o, function(t) { !t && window.checkLoginPromise && (e.isBrokenNetwork = !0) }); break; case408: t.checkLogin(e.uuid).then(o, function(t) { !t && window.checkLoginPromise && (e.isBrokenNetwork = !0) }); break; case400: case500: case0: vars = a.getCookie("refreshTimes") || 0; s < 5 ? (s++, a.setCookie("refreshTimes", s, .5), document.location.reload()) : e.isNeedRefresh = !0; break; case202: e.isScan = !1, e.isAssociationLogin = !1, a.setCookie("login_frequency", 0, 2), window.checkLoginPromise && (window.checkLoginPromise.abort(), window.checkLoginPromise = null), r() } e.code = c.code, e.userAvatar = c.userAvatar, a.log("get code", c.code)}
4.3 小结
微信网页端扫码登录时，轮询的数据返回采用的是JSONP的形式，这是为了解决跨域问题。如对JSONP不了解的，可以参考：http://www.52im.net/thread-1038-1-1.html
微信网页端扫码登录时，轮询采用了后台根据扫码情况阻塞前台请求，优化轮询及减少前端的无效轮询。这种技术，请详见：http://www.52im.net/thread-338-1-1.html
5、本文小结
扫码登录这个功能，现在已经不只出现有IM应用里，各种带有移动端的线上网站也都有了这个功能，所以本文中介绍的技术原理并不局限于只用于实现IM应用中的扫码登录。
另外，为了方便抓取真实的数据进行分析研究，本文中的PC端案例分析是针对的是网页端，但实际上如果你的PC端是富客户端（也就是.exe、.dmg这样的安装版），原理也是一样的，而且还不需要考虑浏览器里的跨域问题等。
阅读本文时，可能涉及到传统的Web端即时通讯技术（为了扫码登录的实时性），比如长轮询等，如果您对这些技术还不太了解的话，可以系统学习一下即时通讯网整理的有关Web端即时通讯方面的资料。
1概述
在日常Web端产品的使用中，一般都会支持扫码登录，这种方式操作简单，相对传统的手机号登录等方式速度更快、安全性更高，还可以增加自家产品的粘合度。
2登录原理
扫码登录本质是解决将APP端的用户登录信息（通常是Token）通过扫码的形式安全稳定地同步给Web端。
1）用户打开Web端网页，进入扫码登录的界面；
2）从Web端服务器获取二维码的图并获取其状态；
3）Web端服务器在生成二维码时，会生成一个uuid和二维码进行关联，并将uuid存入db记录中；
4）用户打开APP端，对着二维码进行扫码授权操作；
5）APP客户端从二维码中读取到uuid，带着APP内的身份信息访问APP端服务器；
6）APP端服务器获取到用户的身份信息后，将用户id更新到db中对应uuid的记录中，此时Web服务器就能拿到对应的用户id，之后生成登录身份信息返回给浏览器，即用户在Web端完成了登录；
3实现方案
基于以上分析，我们可以将扫码登录分为两个步骤：获取扫码状态和获取用户登录信息。
3.1获取扫码状态
用户在Web端页面看到二维码信息后，会使用客户端进行扫码授权，而Web端需要尽快获取到二维码的状态(已扫码、已过期、已取消、已授权)并同步到网页中展示给用户,现在有3种方案：
3.1.1长链接
Web端访问服务器获取二维码状态时，服务器是阻塞了请求，等到二维码的状态变更后才会返回结果，这种请求都会有超时配置(通常是几分钟)，但又不能无限等待。
方案优点：
减少不必要的资源访问浪费；
可以准确区分恶意访问(扫描漏洞，后面的部分会对这部分进行阐述)并进行限流；
当二维码状态变更时，相对于下面的定时轮询方案有更快的响应速度；
方案缺点：
占用服务端大量连接数；
由于超时时间通常比较长，需要web端和nginx对这些请求进行特殊的超时配置；
3.1.2轮询
Web端每隔一个固定时间(为了更好的用户体验通常选择为1秒)访问服务器获取二维码的状态并进行展示。
方案优点：
符合常规思维，开发模式比较简单易维护；
相比阻塞等待方案能够快速释放服务端的连接；
对于服务端的变更升级也更加友好，因为变更升级会导致服务重启，采用阻塞方案则可能会造成部分连接断开；
方案缺点：
如果扫码登录请求访问量大，会导致服务端的访问量一直处于高位；
产生了大量的无用访问，造成资源浪费；
无法准确区分恶意访问并对其进行合理限流；
3.1.3长轮询
长轮询即结合了长链接和定时轮询的优点，Web端访问服务器获取二维码状态时，服务器依然会阻塞了请求，但是超时时间会相对比较短(比如15秒)，超时后Web端会继续发起请求，如此往复。
方案优点：
结合了阻塞等待和定时轮询的优点，削弱了两个方案的的缺点；
方案缺点：
让Web端开发逻辑更加复杂，相当于同时实现了两种方案；
3.1.4方案选择
三种方案各有优缺点，应该结合业务进行选择，先看看各大厂家的选择：
| 平台 | 方案 |
|---|---|
| 微信开放平台 | 长轮询 |
| 微信公众号 | 轮询 |
| 京东 | 轮询 |
| 淘宝&&天猫 | 轮询 |
| 百度 | 长轮询 |
| B站 | 轮询 |
| 快手 | 长链接 |
从上面可以看出目前主流方案是定时轮询，这是由于扫码登录本身也是低频操作，并不会造成很大量的请求，但优点又比较突出。
3.2获取登录信息
当用户扫码登录后，Web服务器如何将用户信息（如Token）同步给Web端。
3.2.1返回Token
指直接返回用户登录信息Token。
方案优点：
流程简单，完成扫描授权后流程后直接结束；
方案缺点：
无法支持多站点跨站登录，即Web端服务器只能给一个业务提供扫码登录功能；
由于直接返回了Token，安全风险等级较高；
3.2.2授权Ticket
Web端服务器在扫码完成后，返回的是一个授权Ticket（也可以直接返回带Ticket的授权url,便于Web端直接跳转），之后需要Web端带着这个Ticket调用目标服务器的接口进行身份的验证同步，如图所示：
点击加载图片
方案优点：
没有直接传递Token，安全性更好；
可以支持多站点跨站登录身份信息的同步，适用于服务于多站点的扫码登录服务；
方案缺点：
实现逻辑较为复杂，需要维护完整的授权Ticket生成、校验以及失效逻辑；
3.2.3方案选择
4安全防护
前面提到，扫码登录的本质是通过扫码手段安全稳定地同步用户信息。那么我们可以通过哪些手段提高同步过程中的安全性？
4.1定时过期
每个二维码都有一个唯一的uuid与之对应，为了防止恶意人员通过接口遍历查询以获取之前已经被扫的二维码信息，数据不能永久存储于db中，需要完成扫码后从db删除或者定期过期清除。
4.2UUID不可遍历
简单的方案是将自增ID和一个固定salt进行md5之后生成一个字符串作为uuid；也可以通过UUID.randomUUID生成一个随机字符串。当然，还可以采用对称加密的方式存储一些加密信息。
4.3签名验证
这个方式关键点在于将uuid和请求中的Cookie或参数信息经过哈希算法得到一个signature值，此时即使有人破解了uuid的生成规则，只能生成uuid，但是无法获知对应uuid生成时对应的Web端状态(Cookie)，因此破解了uuid后也无法获取对应signature值，也就无法获取二维码状态。
4.4合理限流
一般是在获取二维码阶段对来源IP进行访问的限制。
当然扫描二维码阶段也可以做限流，但是如果采用是定时轮询方案，由于访问次数太多，无法做到精确识别和控制，可操作性不强；而如果采用的是阻塞等待方案，也能进行限流，但是如果已经采用了上面参数签名验证，则可以把恶意用户都收口在获取二维码阶段，在这个阶段限流的意义不大。
5总结
其实每个方案都有其适用的场景和阶段，没有严格意义上的孰优孰劣，这个从各互联网公司的选择中也能看出，而要基于自身的需要选择最合适的方案，切忌盲目选择最复杂的方案。