JS二维码扫码登录原理详解：从Token认证到状态流转

近期在极客时间观看了一期关于二维码的视频，内容详实且富有启发性，此处对核心要点进行梳理与总结。

二维码已渗透至日常生活的诸多场景，涵盖超市支付、系统登录及应用下载等环节。深入理解其原理，有助于技术人员在技术选型时拓宽思路；对于普通用户而言，这不仅能消除疑惑，更能提升对各类二维码的辨识能力，有效防范潜在的安全风险。

二维码如今已极为普及。

无论是购物支付、就餐结账，还是乘坐公共交通，扫码已成为常见操作。

在频繁使用扫码功能时，用户难免产生安全疑虑：二维码是否具备安全性？个人信息是否存在泄露风险？部分进阶用户甚至开始思考：自己的业务系统是否也能引入二维码推广机制？

要解答上述疑问，必须深入探究二维码背后的技术架构与逻辑流程。

二维码最典型的应用场景之一，便是通过手机端应用扫描PC或Web端展示的二维码，从而完成同一系统的登录操作。例如，使用手机微信扫码登录PC版微信，或利用手机淘宝扫码登录PC版淘宝。接下来，我们将详细解析这一过程的具体操作步骤。

二维码登录的本质

扫码登录本质上属于一种登录认证方式。既然是认证，核心任务便归结为两点。

第一，向系统声明身份归属。

第二，向系统证明身份真实。

以传统的账号密码登录为例，输入的账号用于声明身份，输入的密码则用于证明身份；在手机验证码登录中，手机号用于声明身份，验证码用于证明身份。

那么，扫码登录是如何实现这两项核心任务的？让我们逐步剖析。

当手机端应用扫描PC端二维码并确认后，PC端即完成登录。此时，PC端登录的账号必然与手机端一致，绝不可能出现手机端登录账号A，而PC端扫码后登录账号B的情况。

因此，第一项任务“声明身份”相对直观。

通过扫描二维码，手机端的信息被传递至PC端，具体传递机制将在后文详述。

至于第二项任务“证明身份”，用户在扫码过程中并未输入密码、验证码或其他凭证，系统如何完成验证？

部分读者可能猜测扫码过程传输了密码，但这在安全层面是不可行的，因为客户端绝不会存储明文密码。深入分析可知，手机端APP在扫码前通常已处于登录状态，即手机端已通过认证流程。所说只要扫码确认是这个手机且是这个账号操作的，其实就能间接证明我谁。

认识二维码

具体的确认机制将在后文详述，在此之前，我们需要先了解二维码的基础知识。为了更好理解，我们先回顾一维码的概念。

一维码即常见的条形码，如超市商品上的条码。它本质上是一串数字，存储了商品的序列号信息。

二维码与条形码原理相似，区别在于其存储内容不限于数字，还可以是任意字符串。简而言之，二维码可视为字符串的一种可视化表现形式。

在搜索引擎中查找“二维码”，可发现众多在线生成工具，如草料二维码网站，它们提供字符串与二维码之间的相互转换功能。

在工具左侧输入框中，用户可输入文本、网址或文件内容等，系统随即生成对应的二维码。

反之，上传二维码图片进行“解码”，即可解析出二维码所代表的原始含义。

系统认证机制

了解二维码基础后，我们需要进一步探讨移动互联网环境下的系统认证机制。

前文提及，出于安全考虑，手机端不存储登录密码。但在实际使用中，用户会发现，仅在应用首次下载并登录时需输入账号密码，此后即便应用进程被终止或手机重启，也无需再次输入密码，系统支持自动登录。

这一便捷体验的背后，是一套基于Token的认证机制。下面我们将解析该机制的运行流程。

在账号密码登录时，客户端会将设备信息一并发送至服务端。若账号密码校验通过，服务端会将账号与设备进行绑定，并存入一个包含账号ID、设备ID及设备类型等字段的数据结构中。

const token = {
  acountid:'账号ID',
  deviceid:'登录的设备ID',
  deviceType:'设备类型，如 iso,android,pc......',
}

随后，服务端生成一个Token，用于映射上述数据结构。Token本质上是一串具有特定意义的字符串，其核心价值在于能够通过它检索到对应的账号与设备信息。

• 客户端获取Token后，需将其本地保存，并在后续每次访问系统API时，随请求携带该Token及设备信息。
• 服务端依据Token查找绑定的账号与设备信息，并将其与客户端每次请求携带的设备信息进行比对。若两者一致，则校验通过，返回API响应数据；若不一致，则校验失败，拒绝访问。

从上述流程可见，客户端无需也不应保存用户密码，而是保存Token。部分读者可能担忧：若Token被他人获取怎么办？实际上，由于设备信息具有唯一性，只要攻击者不知晓原设备的设备信息，即便持有Token，使用其他设备访问时验证仍会失败。

换言之，客户端登录的核心目的，即是获取专属的Token。

那么在扫码登录场景中，PC端如何获取属于自己的Token？手机端显然不能直接将Token共享给PC端，因为Token具有私有性，其他客户端无法使用。在深入分析此问题前，有必要梳理扫码登录的一般步骤，以厘清整体流程。

扫描二维码登录的一般步骤

大概流程

大致流程如下：

1、扫码前，手机端应用需保持已登录状态，PC端展示二维码并等待扫描。

2、手机端打开应用，扫描PC端二维码，扫描成功后，界面提示“已扫描，请在手机端点击确认”。

3、用户在手机端点击确认按钮后，PC端登录即告成功。

观察可知，二维码在过程中经历三种状态：待扫描、已扫描待确认、已确认。据此可推断：

1、二维码背后必然存在一个唯一ID。生成二维码时，该ID同步生成，并与PC端设备信息绑定。

2、手机端扫描该二维码。

3、二维码状态切换为“已扫描待确认”，此时系统将手机端账号信息与该ID绑定。

4、当手机端确认登录时，系统生成用于PC端登录的Token，并返回给PC端。

至此，基本思路已清晰，接下来我们将具体化整个流程。

二维码准备

按二维码的不同状态划分，首先是等待扫描阶段。当用户打开PC端并切换至二维码登录界面时：

1、PC端向服务端发起请求，声明需要生成用户登录二维码，并同步传递PC端设备信息。

2、服务端接收请求后，生成二维码ID，并将该ID与PC端设备信息进行绑定。

3、服务端将生成的二维码ID返回给PC端。

4、PC端接收二维码ID后，生成对应的二维码（二维码内容必然包含该ID）。

5、为实时掌握二维码状态，PC端在展示二维码后，会持续轮询服务端，例如每秒请求一次，以获取当前二维码的状态及相关信息。

二维码准备就绪，接下来进入扫描状态。

扫描状态切换

1、用户使用手机扫描PC端二维码，通过解析二维码内容获取其中的二维码ID。

2、手机端调用服务端API，将移动端的身份信息与二维码ID一并发送至服务端。

3、服务端接收数据后，将身份信息与二维码ID绑定，并生成临时Token，随后返回给手机端。

4、由于PC端持续轮询二维码状态，此时状态发生变更，PC端界面可将二维码状态更新为“已扫描”。

为何需要返回临时Token？临时Token与常规Token类似，均作为身份凭证，区别在于其具有单次有效性，使用后即失效。

在第三步返回临时Token，旨在确保手机端在后续操作中可将其作为凭证。此举保证了“扫码”与“登录”两个步骤均由同一部手机端发起，从而提升安全性。

状态确认

最后阶段为状态确认。

1、手机端接收临时Token后，弹出确认登录界面。用户点击确认后，手机端携带该临时Token调用服务端接口，通知服务端“已确认”。

2、服务端接收确认信息后，根据二维码ID绑定的设备信息与账号信息，生成用于PC端登录的正式Token。

3、此时，PC端的轮询接口可获知二维码状态已变为“已确认”，并从服务端获取到用户登录所需的Token。

4、至此，登录流程完成，PC端即可使用该Token访问服务端资源。

扫码动作的基础流程已阐述完毕，部分细节尚未深入探讨。

• 例如，二维码的具体内容是什么？
• 它可能是单纯的二维码ID，也可能是包含二维码ID的URL地址。此外，在扫码确认环节若用户取消操作，系统应如何处理？这些细节留给读者思考。

总结

我们从登录的本质出发，探索了二维码扫码登录的实现方式。

核心要点包括：

1、向系统声明身份。

2、向系统证明身份。

• 在此过程中，我们简要介绍了两个前提知识：
• 一是二维码的基本原理。

二是基于Token的认证机制。

随后，我们以二维码状态变化为轴线，分析了其背后的逻辑：通过Token认证机制与二维码状态流转来实现扫码登录。

此外，通过第三方应用扫码登录也是常见场景，例如极客时间或掘金支持微信或QQ扫码登录，这种基于第三方应用的扫码登录原理如下：

此外，还有一种常见场景是通过第三方应用扫码登录，例如在极客时间或掘金平台选择微信或QQ扫码登录。这种通过第三方应用扫码登录的原理又是什么？