移动端登录认证机制
当我们在手机应用中第一次登录时，需要手动输入账号密码，之后就可以自动登录，依赖的是一套基于token的认证机制
一般流程如下;
- 第一次登录时，移动端将设备信息 连同账号密码一起传递给服务器
- 如果账号密码校验通过，服务器就会把账号与设备进行绑定，生成一个token，并将token作为key，将账号、设备信息(例如：设备ID、设备类型)作为value，做持久化存储
- 服务器将token返回给移动端，移动端将token存在本地
之后每次访问系统：
- 移动端带上token和设备信息，向服务器发起请求
- 服务器通过token找到 对应的账号与设备信息，将其与移动端带过来的信息进行比对
扫码登录的原理分析
这里只分析最常见的一个场景：
- 移动端处于登录状态，PC端显示二维码，等待扫描
- 用户使用移动端的相机 扫描二维码，PC端提示“已扫描，请在移动端点击确认”
- 用户在移动端点击确认，PC端登录成功
在这个过程中，二维码共有3种状态：
- 阶段A：已生成，待扫描
- 阶段B：已扫描，待确认
- 阶段C：已确认
接下来我们就逐个阶段来分析
阶段A：二维码准备
当用户在PC端打开页面，点击“扫码登录”后：
- PC端携带自己的设备信息向服务器发起请求，请求生成二维码
- 服务器收到后，生成二维码ID，将其与PC端设备信息进行绑定，返回二维码ID
- PC端收到二维码ID后，生成二维码
- 为了及时知道二维码的状态，PC端会不断轮询服务器
阶段B：扫描状态切换
- 用户用移动端的相机去扫描PC端的二维码，提取出二维码ID
- 移动端向服务器发送自己的身份信息和二维码ID
- 服务器接收到后，将身份信息和二维码ID进行绑定，生成临时token，返回给移动端
- 因为PC端一直在轮询，所以这时候二维码状态发生变化，在PC端界面上显示“已扫描，请在移动端点击确认”
这里说到的临时token也是一种身份凭证，只能使用一次，目的是：
确保 扫码、登录这两步操作是同一个移动端设备发出的
阶段C：状态确认
移动端接收到临时token后弹出确认界面，用户点击确认后：
- 移动端携带临时token向服务器发起请求
- 服务器收到确认后，生成PC端登录的token
- 因为PC端一直在轮询，所以这时候二维码状态变为“已确认”，并且获取到服务器返回的token（对应PC端账号、设备信息）
至此，PC端登录成功，之后就可以携带token来访问服务器资源了
