用一句话概括：扫码登录本质上是请求登录方请求已登录方将登录凭证写入特定媒介的过程。这里的请求登录方为 Web 端，已登录方为 APP 端，登录凭证可以是用户信息，也可以是换取用户信息的凭证，而特定媒介是某一张二维码。 具体的扫码登录流程如下：

1. 打开登录页面，展示一个二维码，同时轮询二维码状态(web)
2. 打开APP扫描该二维码后，APP显示确认、取消按钮(app)
3. 登录页面展示被扫描的用户头像等信息(web)
4. 用户在APP上点击确认登录(app)
5. 登录页面从轮询二维码状态得知用户已确认登录，并获取到登录凭证(web)
6. 页面登录成功，并进入主应用程序页面(web)

整个过程中，一张特定二维码起到了连接请求登录方和已登录方桥梁的作用。而二维码本质上就是通过某种约定的编码方式将一段文本信息转换为一个能够被解码识别的图片，其本质就是一段文本信息。所以，我们可以将二维码 ID、创建时间、过期时间等信息写入二维码，APP 终端通过解码二维码信息（这是终端媒介具备的基础功能），就能够识别出此二维码。 在 Web 端，一般会有一个请求生成二维码的接口，此接口会返回二维码 ID 和二维码连接，ID 用于查询二维码最新状态，链接用于展示。 这样，Web 端和 APP 端就建立起了一个共识：二维码 ID。APP 端通过授权修改二维码状态，Web 端能通过轮询监听到二维码状态变化，并获取到登录凭证，从而完成登录。 再来详细分解一下，二维码一共具有哪些状态：

• 未扫描
• 已扫描，等待用户确认
• 已扫描，用户同意授权
• 已扫描，用户取消授权
• 已过期

APP 可以修改二维码状态，一共会用到三个接口：

• 确认已扫描
• 同意授权
• 取消授权

一旦 Web 端监听到二维码状态变成了同意授权，登录就完成了。 APP 端请求这些接口时，需要带上登录凭证（这是显然的），后端接口能够从此判断同意授权的用户，从而将二维码 ID 和用户 ID 绑定起来。 更多内容，可见：

• 扫码登录实战系列 1: 原理及流程设计 (opens new window)
• 扫码登录实战系列 2: 后端接口实现 (opens new window)
• 扫码登录实战系列 3: 前端 SDK 封装 (opens new window)
• 扫码登录实战系列 4: 总结 (opens new window)