權限認證 cookie VS token
我前公司的應用都是 token 授權的，現公司都是維護一個 session 確認登錄狀態的。那么我在這掰扯掰扯這兩種權限認證的方方面面。
工作流程
先說 cookie
cookie 登錄是有狀態的，服務端維護一個 session 客戶端維護一個 cookie，cookie 只保留 sessionID 服務端要保存並跟蹤所有活動的 session 如下：
- 輸入用戶名密碼登陸。
- 服務器拿到身份並驗證后生成一個 session 存到數據庫。
- 把 sessionID 返回給客戶端存成一個 cookie 保存 sessionID。
- 隨后的請求會攜帶這個包含 sessionID 的 cookie。
- 服務器拿着 sessionID 找到對應的 session 認證用戶是否有對應權限啊。
- 登出后，服務端銷毀 session 客戶端銷毀 cookie。
token
token 的認證方式是無狀態的，服務端不保存登陸狀態，也不關心哪些客戶端簽發了 token ，每個請求都會攜帶 token 通常在 header 中，也可以出現在 body 和 query 如下：
- 輸入用戶名密碼登陸。
- 服務器拿到身份並驗證后簽發一個 token。
- 客戶端拿到 token 並存起來，好多地方都可以存。
- 客戶端發送的每一個請求都要攜帶 token，好多方式可以攜帶。
- 服務器接收請求后拿到 token 並解析，拿解析的結果進行權限認證(token中可能已經攜帶權限信息,能被正常解析的 token 被認為是合法機構簽發的)。
- 登出后，在客戶端銷毀 token 即可。
無圖無真相，兩種方式對比
token 的優勢
新的東西如果沒有原來的好用是不會有人用的。那 token 哪里好呢。
- 無狀態，token 是無狀態的，服務器端不需要保留任何信息，每個 token 都會包含所有需要的用戶信息。服務器端可以只負責簽發和解析 token 解放了部分服務器資源，讓服務器更單純的提供接口。
- 跨服務器，無狀態優勢在此。服務器如果做了負載均衡之類的，你兩條請求不一定去同一個服務器，着如果用服務器維護一個 session 的話就顯得有些棘手了，一個服務器和一個客戶端對應，另一個服務器不一定認得你啊，不對是一定不認得你啊，當然這個問題也不難解決。
- 可以攜帶其他信息,比如攜帶具體權限信息之類的，省的還要去查庫。
- 性能，解 token 可比查庫要省事兒的多。
- 跨域，請求需要跨域的接口的時候 cookie 就力不從心了，不同域就不會攜帶 cookie ，不攜帶 cookie 服務器也不知道是哪個 session 啊，token 在此優勢明顯。
- 配合移動端，cookie 是瀏覽器端的玩意兒，移動端應用想使用 cookie 還得折騰一下，token 就方便得多。token 讓服務器端單純提供 API 服務，適用性更廣。
- CSRF，如果 token 不存放在 cookie 中，防止了跨站請求偽造帶來的安全性風險。
參考：地址