權限認證 cookie VS token

權限認證 cookie VS token

我前公司的應用都是 token 受權的，現公司都是維護一個 session 確認登陸狀態的。那麼我在這掰扯掰扯這兩種權限認證的方方面面。

工做流程

先說 cookie

cookie 登陸是有狀態的，服務端維護一個 session 客戶端維護一個 cookie，cookie 只保留 sessionID 服務端要保存並跟蹤全部活動的 session 以下：

1. 輸入用戶名密碼登錄。
2. 服務器拿到身份並驗證後生成一個 session 存到數據庫。
3. 把 sessionID 返回給客戶端存成一個 cookie 保存 sessionID。
4. 隨後的請求會攜帶這個包含 sessionID 的 cookie。
5. 服務器拿着 sessionID 找到對應的 session 認證用戶是否有對應權限啊。

6. 登出後，服務端銷燬 session 客戶端銷燬 cookie。

   token

   token 的認證方式是無狀態的，服務端不保存登錄狀態，也不關心哪些客戶端簽發了 token ，每一個請求都會攜帶 token 一般在 header 中，也能夠出如今 body 和 query 以下：
7. 輸入用戶名密碼登錄。
8. 服務器拿到身份並驗證後簽發一個 token。
9. 客戶端拿到 token 並存起來，好多地方均可以存。
10. 客戶端發送的每個請求都要攜帶 token，好多方式能夠攜帶。
11. 服務器接收請求後拿到 token 並解析，拿解析的結果進行權限認證(token中可能已經攜帶權限信息,能被正常解析的 token 被認爲是合法機構簽發的)。

12. 登出後，在客戶端銷燬 token 便可。
    無圖無真相，兩種方式對比
    

    token 的優點

    新的東西若是沒有原來的好用是不會有人用的。那 token 哪裏好呢。

• 無狀態，token 是無狀態的，服務器端不須要保留任何信息，每一個 token 都會包含全部須要的用戶信息。服務器端能夠只負責簽發和解析 token 解放了部分服務器資源，讓服務器更單純的提供接口。
• 跨服務器，無狀態優點在此。服務器若是作了負載均衡之類的，你兩條請求不必定去同一個服務器，着若是用服務器維護一個 session 的話就顯得有些棘手了，一個服務器和一個客戶端對應，另外一個服務器不必定認得你啊，不對是必定不認得你啊，固然這個問題也不難解決。
• 能夠攜帶其餘信息,好比攜帶具體權限信息之類的，省的還要去查庫。
• 性能，解 token 可比查庫要省事兒的多。
• 跨域，請求須要跨域的接口的時候 cookie 就力不從心了，不一樣域就不會攜帶 cookie ，不攜帶 cookie 服務器也不知道是哪一個 session 啊，token 在此優點明顯。
• 配合移動端，cookie 是瀏覽器端的玩意兒，移動端應用想使用 cookie 還得折騰一下，token 就方便得多。token 讓服務器端單純提供 API 服務，適用性更廣。
• CSRF，若是 token 不存放在 cookie 中，防止了跨站請求僞造帶來的安全性風險。
  參考：地址