權限認證 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 中，防止了跨站請求偽造帶來的安全性風險。
  參考：地址

權限認證 cookie VS token