一图搞懂扫码登录的技术原理 _扫码登录

现在扫码登录是一种很常见的登录方式。当用户需要登录某个网站时，网站会提供一种扫码登录的方式，用户打开相应的手机App，扫描网站上显示的二维码，然后在App中确认登录，网站监测到用户确认登录后，跳转到登录成功页面。从这个形式上看，扫码登录就是将用户在手机App中的登录状态同步到网站中，这篇文章就来一窥这个同步是如何发生的。
同一产品中的扫码登录假设有一款产品，这个产品通过手机端App和PC端应用为用户提供服务，为了方便用户在PC端上登录，产品提供了一个扫码登录的功能，即PC端应用上展示一个登录二维码，用户使用手机端App扫码并确认登录，然后用户就可以在PC端上登录成功。在这个例子中，手机端App和PC端应用同属于一个产品，这是一种常见的产品形态，微信、微博、知乎等等都是这种产品形态的代表。
为了方便介绍，这里再假设PC端应用是一个Web站点，下面就来看一下这种登录方式的运作原理：

文章插图

如上图所示，整个过程比较简单，这里大概分为如下几个步骤：
1、用户发起二维码登录：此时网站会先生成一个二维码，同时把这个二维码对应的标识保存起来，以便跟踪二维码的扫码状态，然后将二维码页面返回到浏览器中；浏览器先展示这个二维码，再按照JAVAscript脚本的指示发起扫码状态的轮询。所谓轮询就是浏览器每隔几秒调用网站的API查询二维码的扫码登录结果，查询时携带二维码的标识。有的文章说这里可以使用WebSocket，虽然WebSocket响应比较及时，但是从兼容性和复杂度考虑，大部分方案还是会选择轮询或者长轮询，毕竟此时通信稍微延迟下也没多大关系。
2、用户扫码确认登录：用户打开手机App，使用App自带的扫码功能，扫描浏览器中展现的二维码，然后App提取出二维码中的登录信息，显示登录确认的页面，这个页面可以是App的Native页面，也可以是远程H5页面，这里采用Native页面，用户点击确认或者同意按钮后，App将二维码信息和当前用户的Token一起提交到网站API，网站API确认用户Token有效后，更新在步骤1中创建的二维码标识的状态为“确认登录”，同时绑定当前用户。
3、网站验证登录成功：在步骤1中，二维码登录页面启动了一个扫码状态的轮询，如果用户已经“确认登录”，则轮询访问网站API时，网站会生成二维码绑定用户的登录Session，然后向前端返回登录成功消息。这里登录状态维护是采用的Session机制，也可以换成其它的机制，比如JWT 。
为了保证登录的安全，有必要采取一些安全措施，可能包括以下若干方法：

对二维码承载的信息按照某种规则进行处理，App可以在扫码时进行验证，避免任何扫码都去请求登录；

对二维码设置一个过期时间，过期就自动删除，这样使其占用的资源保持在合理范围之内；

限制二维码只能使用一次，防止重放攻击；

二维码使用足够长的随机性字符串，防止被恶意穷举占用；

使用HTTPS传输，保护登录数据不被窃听和篡改。

第三方应用的扫码登录现在很多网站除了提供自身账号的登录方式以外，还提供了微信扫码登录、微博扫码登录等方式，本来这对用户来说是十分方便的，不过很多站点为了获取用户手机号，首次登录时还需要用手机验证码再登录一次，用户会有点被欺骗的感觉，不过这个问题不是本文要探讨的。
这里以微信扫码登录某网站为例，某网站就是第三方应用，所谓第三方是相对微信自身来说的。相比同一产品中的扫码登录，网站使用微信扫码登录会更复杂一些，因为这涉及到不同应用之间的登录安全。下面就给出这一登录方式的详细运作原理，时序图比较长，不过只要耐心点就能完全搞清楚，甚至自己实现一个类似的第三方扫码登录方案。

文章插图

这里对一些关键点特别说明下：
1、步骤3 生成微信登录请求记录：当用户扫码并同意登录之后，步骤25中浏览器会重定向到第三方应用，如果之前没有创建一条登录请求记录，网站并不能确定这次登录就是自己发起的，这可能导致跨站请求伪造攻击。比如使用某个应用的微信登录二维码，骗取用户的授权，然后最终回调跳转到其它站点，被回调站点只能被动接受，虽然下一步验证授权Code通不过，微信也可能会认为第三方应用出了某种问题，搞不好被封掉。因此第三方应用创建一条登录请求记录之后，还要把记录的标识拼接到访问微信登录二维码的url中，微信会在用户同意登录后原样返回这个标识，步骤26中第三方应用可以验证这个标识是不是有效的。