当前位置：网站首页>JSON Web Token----JWT和傳統session登錄認證對比

JSON Web Token----JWT和傳統session登錄認證對比

2022-07-04 05:55: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 同步問題；

經過改造之後變成了如下的認證過程：