当前位置：网站首页>JSON Web Token----JWT和传统session登录认证对比

JSON Web Token----JWT和传统session登录认证对比

2022-07-04 05:53:00 【Rk..】

1、什么是JWT

2、传统的Cookie-Session认证

2.1、登录认证流程

2.2、缺点

2.3、springboot的单体项目使用传统session实现登录和认证

3、Cookie-Session认证升级版----redis实现session共享

4、基于JWT认证

4.1、认证流程

4.2、使用JWT的优势

1、什么是JWT

JWT简称JSON Web Token,也就是通过JSON形式作为Web应用中的令牌,用于在各方之间安全地将信息作为JSON对象传输。在数据传输过程中还可以完成数据加密、签名等相关处理。Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准。该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

单点登录:

单点登录的英文名叫做：Single Sign On（简称SSO）。在以前的时候，一般我们就单系统，所有的功能都在同一个系统上。后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。

比如阿里系的淘宝和天猫，很明显地我们可以知道这是两个系统，但是你在使用的时候，登录了天猫，淘宝也会自动登录。简单来说，单点登录就是在多个系统中，用户只需一次登录，各个系统即可感知该用户已经登录。

2、传统的Cookie-Session认证

2.1、登录认证流程

1、客户端向服务端发送账号密码进行认证。

2、服务端在校验账号密码正确之后，将当前用户的基本信息保存到当前会话（session）中，并将sessionid(JESSIONID)返回给客户端。

3、客户端在拿到sessionid之后将其保存到cookie中，并在以后的每次请求中cookie都携带该sessionid。sessionid相当于key，session相当于value,服务器通过sessionid来获取session

4、服务端根据客户端传过来的sessionid对当前用户进行认证，判断是否合法。

2.2、缺点

1、Session: 每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。

2、扩展性: 用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。而且如果你后端应用是多节点部署。那么就需要实现session共享机制。不方便集群应用。

3、CSRF: 因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击

4、Cookie-Session 只能在 web 场景下使用，如果是 APP 呢，APP 可没有地方存 cookie。
现在的产品基本上都同时提供 web 端和 APP 两种使用方式，有的产品甚至只有 APP

2.3、springboot的单体项目使用传统session实现登录和认证

登录：

    //登录表单发送请求
    @PostMapping("/login")
    public String login(User user, HttpSession session,Model model){
        //省略从数据库查询
        if("luo".equals(user.getUsername())&&"123456".equals(user.getPassword()))
        {
            session.setAttribute("loginUser",user);
            return "redirect:/main.html";//重定向到main页面
        }else {
            model.addAttribute("msg","账号或密码错误");
            return "login";
        }
    }

登录成功后会将sessionid返回给客户端浏览器，存储在cookie中。

拦截器:

   @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //登录检查逻辑  通过sessionid来获取session
        HttpSession session = request.getSession();
        //获取session中存储的对象
        Object loginUser = session.getAttribute("loginUser");
        if(loginUser!=null)//如果不为空，说明已经有用户登录
            return true;//登录 放行
        //拦截住，未登录 跳转到登录页面
        request.setAttribute("msg","请先登录!");
        request.getRequestDispatcher("/login").forward(request,response);
        return false;
    }

每次前端发起请求后，都会先经过这个拦截器。通过前端携带sessionid，然后通过sessionid获取对应的session。然后获取session中存储的对象

测试接口:

    @ResponseBody
    @GetMapping("/list")
    public List<User>  list(){
        //查询所有数据
         List<User> list = userService.list();
         return list;
    }

如果没有登录请求其他接口会被拦截:例如list接口

登录后再次访问list接口:

先登录:

登录成功后会返回一个JESSIONID到cookie里。

再次访问list接口:

3、Cookie-Session认证升级版----redis实现session共享

由于传统的 Cookie-Session 认证存在诸多问题，那可以把上面的方案改造一下。
1、改造 Cookie 既然 Cookie 不能在 APP 等非浏览器中使用，那就不用 cookie 做客户端存储，改用其他方式。
web 中可以使用 local storage，APP 中使用客户端数据库，这样既能这样就实现了跨域，并且避免了 CSRF 。

2、服务端也不存 Session 了，把 Session 信息拿出来存到 Redis中，这样即提高了速度，又避免了 Session 同步问题；

经过改造之后变成了如下的认证过程：