扫码登录详解

发布于:2022-11-09 ⋅ 阅读:(18) ⋅ 点赞:(0) ⋅ 评论:(0)

目录

扫码流程分析

流程详解

步骤一: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攻击问题