Session、Token身份驗證方法
Session ：我發給你一張身份證，但只是一張寫著身份證號碼的紙片。你每次來辦事，我去後臺查一下你的 id 是不是有效。
Token：我發給你一張加密的身份證，以後你只要出示這張卡片，我就知道你一定是自己人。
token和session其實都是為了身份驗證，session一般翻譯為會話，而token更多的時候是翻譯為令牌。
session伺服器會儲存一份，可能儲存到快取，檔案，資料庫。
同樣，session和token都是有過期時間一說，都需要去管理過期時間；其實token與session的問題是一種時間與空間的博弈問題，session是空間換時間，而token是時間換空間。兩者的選擇要看具體情況而定。
雖然確實都是“客戶端記錄，每次訪問攜帶”，但 token 很容易設計為自包含的，也就是說，後端不需要記錄什麼東西，每次一個無狀態請求，每次解密驗證，每次當場得出合法 /非法的結論。這一切判斷依據，除了固化在 CS 兩端的一些邏輯之外，整個資訊是自包含的。這才是真正的無狀態。
而 sessionid ，一般都是一段隨機字串，需要到後端去檢索 id 的有效性。萬一伺服器重啟導致記憶體裡的 session 沒了呢？萬一 redis 伺服器掛了呢？
傳統Session的身份驗證方法
HTTP 是一種沒有狀態的協議，也就是它並不知道是誰是訪問應用。這裡我們把使用者看成是客戶端，客戶端使用使用者名稱還有密碼通過了身份驗證，不過下回這個客戶端再發送請求時候，還得再驗證一下。
解決的方法就是，當用戶請求登入的時候，如果沒有問題，我們在服務端生成一條記錄，這個記錄裡可以說明一下登入的使用者是誰，然後把這條記錄的 ID 號傳送給客戶端，客戶端收到以後把這個 ID 號儲存在 Cookie 裡，下次這個使用者再向服務端傳送請求的時候，可以帶著這個 Cookie ，這樣服務端會驗證一個這個 Cookie 裡的資訊，看看能不能在服務端這裡找到對應的記錄，如果可以，說明使用者已經通過了身份驗證，就把使用者請求的資料返回給客戶端。
上面說的就是 Session，我們需要在服務端儲存為登入的使用者生成的 Session ，這些 Session 可能會儲存在記憶體，磁碟，或者資料庫裡。我們可能需要在服務端定期的去清理過期的 Session 。
1、使用者向伺服器傳送使用者名稱和密碼。
2、伺服器驗證通過後，在當前對話（session）裡面儲存相關資料，比如使用者角色、登入時間等等。
3、伺服器向用戶返回一個 session_id，寫入使用者的 Cookie。
4、使用者隨後的每一次請求，都會通過 Cookie，將 session_id 傳回伺服器。
5、伺服器收到 session_id，找到前期儲存的資料，由此得知使用者的身份。
基於 Token 的身份驗證方法
使用基於 Token 的身份驗證方法，在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的：
-
客戶端使用使用者名稱跟密碼請求登入
-
服務端收到請求，去驗證使用者名稱與密碼
-
驗證成功後，服務端會簽發一個 Token，再把這個 Token 傳送給客戶端
-
客戶端收到 Token 以後可以把它儲存起來，比如放在 Cookie 裡或者 Local Storage 裡
-
客戶端每次向服務端請求資源的時候需要帶著服務端簽發的 Token
-
服務端收到請求，然後去驗證客戶端請求裡面帶著的 Token，如果驗證成功，就向客戶端返回請求的資料
參考
基於 Token 的身份驗證：JSON Web Token（附：Node.js 專案）