扫码登录原理

整体流程如图

大概可以分为三个阶段: 待扫码 -> 已扫码待确认 -> 已确认

待扫码

1. PC 端发送一个创建登录二维码的请求
2. 服务端返回一个二维码地址，以及这个二维码 ID
3. PC 端展示二维码，进入待扫码阶段
4. 同时，也会开启一个轮询，不停的去请求服务端状态，来更新状态
5. 有时候，前端也会有一个过期倒计时

已扫码待确认

1. 扫码时，会向服务端发起一个请求。这个请求会携带: APP 已登录的凭证 token + 二维码 ID
2. 服务端收到请求后，会绑定这个凭证 token 和二维码 ID，生成一个临时 token，响应给 APP 端
3. 同时，这个二维码进入已扫码待确认状态

已确认

1. APP 收到相应后，页面会跳转到一个确认页面。
2. 点击确认登录后，APP 会将带有临时 token 的请求发到服务端
3. 服务端收到临时 token，完成校验后，会为 PC 端生成一个 token，并更新状态为已确认。
4. PC 端轮询到状态变更时，会进行一个页面跳转。

问题

以上是大致流程，应该还有很多细节问题没讲明白，比如

为什么需要手机端的确认？

有一种解释是: 假设没有确认这个环节，攻击者拦截已登录的账号发送的其他请求，获得 token 之后，然后发送 token+网页的二维码 ID，即可成功登录了，不太安全，所以需要最后手机上再确认一步。

但是就这个回答，又有问题，既然已经拦截了请求，那也能拦截临时 token 的请求了，有什么不一样吗？

留有疑问，等有机会再问问专业解答，目前（2023-04-03）搜到的看起来都像是复制粘贴的答案。

参考

• 字节二面：扫码登录的原理
• 二维码扫码登录是什么原理