目录
扫码流程分析
1.扫码前，手机端已经是登陆状态，PC端显示一个二维码，等待扫描。
2.手机端打开应用，扫描PC端的二维码。
3.扫描后，会提示“已扫描，请在手机端点击确认”
4.用户在手机端点击确认，确认后PC端就登陆成功了。
流程详解
步骤一：PC端准备二维码
从二维码的不同状态来看，首先是等待扫描状态，用户打开PC端，切换到二维码登陆界面时，
1.PC端向服务端发起请求，告诉服务端，需要生成用户登陆的二维码，并且把PC端设备信息也传递给服务端。
2.服务端收到请求后，生成二维码ID，并将二维码ID与PC端设备信息进行绑定。
3.服务端将二维码ID返回给PC端
4.PC端收到二维码ID后，生成二维码(二维码中包含了ID)
5.为了知道二维码的状态，客户端在展现二维码后，PC端不断轮询服务端，请求服务端告知当前二维码的状态。
步骤二：扫码，二维码状态改变
1.用户手机扫描PC端的二维码，通过二维码内容取到其中的二维码ID
2.手机端调用服务端 API 将移动端的身份信息与二维码 ID 一起发送给服务端。
3.服务端接收到后，将身份信息与二维码 ID 进行绑定，生成临时 token。
4.将生成的临时token发送给手机端。
5. PC 端一直在轮询二维码状态，所以这时候二维码状态发生了改变，它就可以在界面上把二维码状态更新为已扫描，页面提示“已扫描，请在手机端点击确认”
步骤三：状态确认
1.手机端接收到临时token后会弹出确认登陆界面，用户点击确认时，手机携带临时token，告诉服务器，手机端已确认。
2.服务端收到确认后，根据二维码绑定的设备信息和账号信息，生成用户PC端登陆的token
3.这时候PC端的轮询接口就可以得知二维码的状态已经变成“已确认”，并且服务端可以获取到用户登陆的token
4.登陆成功
token认证机制
为什么 要用token？
1.HTTP是一个无状态的协议，一次请求结束后，下次在发送给服务器，服务器就不知道是谁发来的了(同一个ip不代表同一个用户)，在web应用中，用的认证和鉴权是非常重要的一环。
2.早期，大部分采用基于cookie-session的会话管理方式，但是基于session的方法又存在很多问题：
a：服务器需要存储session，并且由于session需要快速的查找，通常存储在内存或者内存数据库中，同时在线用户较多时需要占用大量的服务器资源。
b：当需要扩展时，创建session的服务器可能不是验证session的服务器，所以还需要将所有的session单独存储并共享。
c：由于客户端使用cookie存储sessionID，在跨域场景下需要进行兼容处理，同时这种方式也难以防范CSRF攻击。
token是什么？
token是服务器生成的一串字符串，作为客户端请求的一个令牌，等第一次登陆后，服务器生成一个token返回给客户端，以后客户端只需要带上这个token前来请求即可，不需要再次带上用户名和密码。提高了安全性。
token的具体逻辑：
1.客户端使用用户名、密码进行认证。
2.服务端验证用户名，密码正确后生成token返回给客户端。
3.客户端保存token，访问需压认证的接口在url参数或者HTTP header中加入token。
4.服务器通过解码进行token授权，返回给客户端需要的数据。
token的优势：
1.服务器不需要存储和用户鉴权相关的信息，鉴权信息会被加密到token中，服务端只需要读取token包含的鉴权信息即可。
2.避免了共享session导致的不易扩展的问题。
3.不需要依赖cookie，有效的避免了cookie带来的CSRF攻击问题
3172
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
