深入探讨抖音二维码扫码登录原理及其背后的技术机制：安全性、用户验证与系统架构详解

在本文中，我们将探讨一位读者在去年秋季招聘中面试抖音时遇到的一个常见问题。近期，我发现了一篇很好的文章对此进行了详细解答，因此想与大家分享。

这种问题在大型企业面试中比较普遍，例如阿里、腾讯、用友、京东和小红书等。

接下来，让我们深入正文。

几天前，我观看了极客时间的一个关于二维码的精彩视频，内容非常出色。在这里，我将总结一下相关要点。

在日常生活中，二维码被广泛应用于各种场景，如超市支付、系统登录和应用下载等。了解二维码的基本原理，对于技术人员在技术选型时，能够提供新的见解。而对于非技术人员来说，掌握二维码的知识不仅能消除疑虑，还能帮助他们更好地辨别生活中的各种二维码，从而避免上当受骗。

二维码已经成为我们生活中不可或缺的一部分

无论是购物、就餐，还是乘坐公共交通，二维码的应用无处不在。

在扫描二维码的过程中，可能会有人疑惑：二维码的安全性如何？是否会泄露我的个人信息？而对于更深入的用户，或许会想：我的系统是否也可以使用二维码来推广呢？

这时候，就有必要了解一下二维码背后的技术与逻辑。

二维码登录本质

二维码登录作为一种登录认证方式，其核心可以归结为两个关键点：

告诉系统我是谁。
向系统证明我是谁。

例如，使用账号密码进行登录时，账号信息就是告诉系统我是谁，而密码则是向系统证明我是谁；再如，使用手机验证码登录时，手机号同样是告诉系统我是谁，验证码则是证明。

那么，扫码登录是如何完成这两项工作的呢？我们来一探究竟。

当手机端应用扫描PC端的二维码并确认后，PC端的登录便会成功。在这种情况下，PC端登录的账号必定与手机端相同，不可能出现手机端使用账号A，而PC端却登录为账号B的情况。

因此，第一步，告诉系统我是谁，显而易见。

通过扫描二维码，手机端的账号信息被成功传递至PC端，至于传递的具体方式，我们稍后会详细探讨。

第二步，向系统证明我是谁。在扫码登录的过程中，用户并没有输入密码、验证码或其它任何代码，究竟如何证明身份呢？

有些人可能会猜测，是否在扫码过程中密码也被传送到了PC端？显然，这是不可能的，因为那样会存在很大的安全隐患。实际上，手机端的应用已经完成了登录认证。这意味着，只要确认是该手机且使用的是该账号进行操作，就能间接证明身份。

认识二维码

在理解如何确认身份之前，我们首先需要了解二维码的基本概念。为了更好地理解二维码，我们先简单了解一下条形码。

条形码，通常出现在超市中，其实就是一串数字，存储了商品的序列号。

二维码与条形码相似，但二维码不仅可以存储数字，还可以包含各种字符串。可以将二维码视为字符串的另一种表现形式。

在搜索引擎中，你可以找到许多在线生成二维码的工具。这些网站可以实现字符串与二维码之间的相互转换，例如草料二维码网站。

在左侧的输入框中，你可以输入任何内容，例如文本、网址或文件，随后便可生成相应的二维码。

此外，你还可以上传二维码并进行“解码”，从而解析出二维码所代表的内容。

系统认证机制

了解了二维码后，我们接下来看看移动互联网中的系统认证机制。

如前所述，为了安全原因，手机端不会存储用户的登录密码。但是在日常使用中，我们通常会发现，只有在应用首次下载并登录时，需要输入账号和密码，之后即使应用进程被杀死或手机重启，用户也无需再次输入账号和密码，系统会自动登录。

这背后实际上是一套基于token的认证机制。我们来看看这套机制的运行过程。

账号密码登录时，客户端会将设备信息一并发送给服务器。
如果账号和密码校验通过，服务器会将账号与设备进行绑定，存储在一个数据结构中，该结构包含了账号ID、设备ID、设备类型等信息。

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

随后，服务器会生成一个token，以映射该数据结构。这个token实际上是一串具有特殊意义的字符串，通过它，我们可以找到对应的账号和设备信息。

客户端获取该token后，将其保存在本地，每次访问系统API时都会携带该token和设备信息。
服务器可以通过token找到与之绑定的账号和设备信息，并将绑定的设备信息与客户端每次传输的设备信息进行比较。如果相同，验证通过，返回API接口响应数据；如果不同，则验证不通过，拒绝访问。

通过这一流程，我们可以看到，客户端并不保存用户的密码，而是保存了token。有些人可能会担心：如果token被他人知悉会有什么影响？实际上，即使知道也无所谓，因为设备信息是唯一的，只要他人不知道你的设备信息，其他设备访问时也无法通过验证。

可以说，客户端登录的目的就是为了获得属于自己的token。

那么在扫码登录的过程中，PC端又是如何获得属于自己的token呢？显然，手机端不可能直接将自己的token传递给PC端！token只能是特定客户端私有的，其他人或客户端无法使用。在探讨这个问题之前，我们有必要先梳理一下，扫描二维码登录的一般步骤是怎样的。这将帮助我们理清整个过程。

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

流程概述

扫码前，手机端应用处于已登录状态，PC端显示二维码，等待扫描。
手机端打开应用，扫描PC端的二维码，扫描完成后，提示“已扫描，请在手机端点击确认”。
用户在手机端点击确认后，PC端的登录便成功了。

可以看到，二维码在此过程中经历了三个状态：待扫描、已扫描待确认、已确认。

二维码背后必然存在一个唯一的ID，当二维码生成时，这个ID也随之生成并与PC端的设备信息绑定。
手机扫描二维码。
二维码状态变为已扫描待确认，此时将账号信息与该ID绑定。
当手机端确认登录时，系统便生成PC端登录所需的token，并返回给PC端。

至此，基本思路已经清晰。接下来，我们将这一过程具体化。

二维码准备

从二维码的不同状态来看，首先是待扫描状态。当用户打开PC端并切换到二维码登录界面时。

PC端向服务器发起请求，告知服务器需要生成用户登录的二维码，并传递PC端设备信息。
服务器接收到请求后生成二维码ID，并将其与PC端设备信息绑定。
然后，将二维码ID返回给PC端。
PC端收到二维码ID后生成二维码（二维码中必然包含该ID）。
为了及时获取二维码的状态，客户端在展示二维码后，PC端会不断进行轮询，比如每隔一秒轮询一次，请求服务器告知当前二维码的状态及相关信息。

二维码准备就绪后，将进入扫描状态。

扫描状态转换

用户用手机扫描PC端的二维码，从中提取二维码ID。
然后调用服务器API，将移动端的身份信息与二维码ID一起发送至服务器。
服务器收到后，将身份信息与二维码ID绑定，生成临时token，并返回给手机端。
此时，PC端持续轮询二维码状态，因此二维码的状态会更新为已扫描。

那么为什么需要返回临时token给手机端呢？临时token与token类似，都是身份凭证，但不同的是它只能使用一次，使用后即失效。

在第三步骤中返回临时token，是为了确保之后的操作是由同一部手机端发出的。

状态确认

最后一步是状态确认。

手机端接收到临时token后，弹出确认登录界面。用户点击确认后，手机端将携带临时token调用服务器接口，向服务器确认已执行。
服务器接收到确认后，根据二维码ID绑定的设备信息与账号信息，生成用户PC端登录的token。
此时，PC端的轮询接口得知二维码状态已变为“已确认”。并从服务器获取用户登录的token。
此时，登录成功，PC端即可使用token访问服务器资源。

扫码流程的基础过程到此为止，某些细节尚未深入探讨。

例如，二维码的内容是什么？

可以是二维码ID。
可以是包含二维码ID的一个URL地址。

在扫码确认的步骤中，若用户取消该操作该如何处理？这些细节留给大家思考。

总结

通过对登录本质的探讨，我们探索了二维码扫码登录如何实现的过程：

告诉系统我是谁。
向系统证明我是谁。

在这一过程中，我们简单介绍了两个前提知识：

二维码原理。
基于token的认证机制。

接着，我们以二维码状态为核心，分析了背后的逻辑：通过token认证机制与二维码状态的变化实现扫码登录。

值得注意的是，上述登录流程适用于同一系统的PC端、WEB端和移动端。

在日常生活中，我们还会遇到另一种常见的场景：通过第三方应用扫码登录。例如，极客时间或掘金等平台，均可选择使用微信或QQ等进行扫码登录。那么，这种通过第三方应用扫码登录的原理又是什么呢？

感兴趣的读者可以深入思考研究，期待在评论区看到你们的见解。

参考资料

[1]极客时间一个二维码的视频: https://time.geekbang.org/dailylesson/detail/100044032

[2]草料二维码网站: https://cli.im/