目录

扫码流程分析

流程详解

步骤一：PC端准备二维码

步骤三：状态确认

token认证机制

扫码流程分析

        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攻击问题