token 我們說的token，是指 訪問資源的憑據 。使用基於 Token 的身份驗證方法，在服務端不需要存儲用戶的登錄記錄。
大致流程：
客戶端使用用戶名跟密碼請求登錄
服務端收到請求，驗證用戶名與密碼
驗證成功后，服務端會簽發一個 Token，再把這個 Token 發送給客戶端
客戶端收到 Token 以后可以把它存儲起來，比如放在localStorage中
客戶端每次向服務端請求資源的時候需要帶着服務端簽發的 Token
服務端收到請求，然后去驗證客戶端請求里面帶着的 Token，如果驗證成功，就放行
1. 優勢
那Token相對於Cookie/Session的好處：
支持跨域訪問: Cookie是不允許垮域訪問的，token支持
無狀態： token無狀態，session有狀態的
去耦: 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，只要在 你的API被調用的時候， 你可以進行Token生成調用即可.
更適用於移動應用: Cookie不支持手機端訪問的
性能: 在網絡傳輸的過程中，性能更好
基於標准化: 你的API可以采用標准化的 JSON Web Token (JWT). 這個標准已經存在 多個后端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如： Firebase,Google, Microsoft）
2 缺陷
1. 占帶寬
正常情況下要比 session_id 更大，需要消耗更多流量，擠占更多帶寬，假如你的網站每月有 10 萬次的瀏覽器，就意味着要多開銷幾十兆的流量。聽起來並不多，但日積月累也是不小一筆開銷。實際上，許多人會在 JWT 中存儲的信息會更多。
2. 無法在服務端注銷，那么久很難解決劫持問題
3. 性能問題
JWT 的賣點之一就是加密簽名，由於這個特性，接收方得以驗證 JWT 是否有效且被信任。但是大多數 Web 身份認證應用中，JWT 都會被存儲到 Cookie 中，這就是說你有了兩個層面的簽名。聽着似乎很牛逼，但是沒有任何優勢，為此，你需要花費兩倍的 CPU 開銷來驗證簽名。對於有着嚴格性能要求的 Web 應用，這並不理想，尤其對於單線程環境。
路漫漫其修遠兮。