基本介绍
相信大家对二维码都不陌生，生活中到处充斥着扫码登录的场景，如登录网页版微信、支付宝等。最近学习了一下扫码登录的原理，感觉蛮有趣的，于是自己实现了一个简易版扫码登录的 Demo，以此记录一下学习过程。
实际上是面试的时候被问到了 ￣△￣！
原理解析
1. 身份认证机制
在介绍扫码登录的原理之前，我们先聊一聊服务端的身份认证机制。以普通的 账号 + 密码 登录方式为例，服务端收到用户的登录请求后，首先验证账号、密码的合法性。如果验证通过，那么服务端会为用户分配一个 token，该 token 与用户的身份信息相关联，可作为用户的登录凭证。之后 PC 端再次发送请求时，需要在请求的 Header 或者 Query 参数中携带 token，服务端根据 token 便可识别出当前用户。token 的优点是更加方便、安全，它降低了账号密码被劫持的风险，而且用户不需要重复地输入账号和密码。PC 端通过账号和密码登录的过程如下：
扫码登录本质上也是一种身份认证方式， 账号 + 密码 登录与扫码登录的区别在于，前者是利用 PC 端的账号和密码为 PC 端申请一个 token，后者是利用 手机端的 token + 设备信息 为 PC 端申请一个 token。这两种登录方式的目的相同，都是为了使 PC 端获得服务端的 "授权"，在为 PC 端申请 token 之前，二者都需要向服务端证明自己的身份，也就是必须让服务端知道当前用户是谁，这样服务端才能为其生成 PC 端 token。由于扫码前手机端一定是处于已登录状态的，因此手机端本身已经保存了一个 token，该 token 可用于服务端的身份识别。那么为什么手机端在验证身份时还需要设备信息呢？实际上，手机端的身份认证和 PC 端略有不同：
- 手机端在登录前也需要输入账号和密码，但登录请求中除了账号密码外还包含着设备信息，例如设备类型、设备 id 等。
- 接收到登录请求后，服务端会验证账号和密码，验证通过后，将用户信息与设备信息关联起来，也就是将它们存储在一个数据结构 structure 中。
- 服务端为手机端生成一个 token，并将 token 与用户信息、设备信息关联起来，即以 token 为 key，structure 为 value，将该键值对持久化保存到本地，之后将 token 返回给手机端。
- 手机端发送请求，携带 token 和设备信息，服务端根据 token 查询出 structure，并验证 structure 中的设备信息和手机端的设备信息是否相同，以此判断用户的有效性。