本文將對比討論cookie-session與JWT
下面這幅圖簡單地說明了cookie-session機制與JWT機制
基于Cookie的身份驗證
基于 Cookie 的身份驗證是長期處理用戶身份驗證的默認的方法。
基于cookie的身份驗證是有狀態的。這意味著驗證的記錄或者會話(session)必須同時保存在服務器端和客戶端。服務器端需要跟蹤記錄session并存至數據庫，同時前端需要在cookie中保存一個sessionID，作為session的唯一標識符，可看做是session的“身份證”。
舉一個栗子，以登錄新浪微博為例，當用戶來到微博登陸頁面，輸入用戶名和密碼之后，點擊“登錄”后，瀏覽器將認證信息POST發送給遠端的服務器，服務器執行驗證邏輯，如果驗證通過，則瀏覽器會跳轉到登錄用戶的微博首頁，在登錄成功后，服務器如何驗證我們對其他受限制頁面的訪問呢？
因為HTTP協議是無狀態的，所以很顯然服務器不可能知道我們已經在上一次的HTTP請求中通過了驗證。最簡單的解決方案就是所有的請求里面都帶上用戶名和密碼，這樣雖然可行，但大大加重了服務器的負擔（對于每個request都需要到數據庫驗證），也大大降低了用戶體驗(每個頁面都需要重新輸入用戶名密碼，每個頁面都帶有登錄表單)。既然直接在請求中帶上用戶名與密碼不可行，那么就只有在服務器或客戶端保存一些類似的可以代表身份的信息了，所以就有了cookie與session。
cookie
cookie，簡而言之就是在客戶端（瀏覽器等）保存一些用戶操作的歷史信息（當然包括登錄信息），并在用戶再次訪問該站點時瀏覽器通過HTTP協議將本地cookie內容發送給服務器，從而完成驗證，或繼續上一步操作。
session
session,會話，簡而言之就是在服務器上保存用戶操作的歷史信息，在用戶登錄后，服務器存儲用戶會話的相關信息，并為客戶端指定一個訪問憑證，如果有客戶端憑此憑證發出請求，則在服務端存儲的信息中，取出用戶相關登錄信息，并且使用服務端返回的憑證常存儲于Cookie中,也可以改寫URL，將id放在url中。這個訪問憑證一般來說就是SessionID。
小結
session和cookie的目的相同，都是為了克服http協議無狀態的缺陷，但完成的方法不同。
session可以通過cookie來完成，在客戶端保存session id，而將用戶的其他會話消息保存在服務端的session對象中，與此相對的，cookie需要將所有信息都保存在客戶端。因此cookie存在著一定的安全隱患，例如本地cookie中保存的用戶名密碼被破譯，或cookie被其他網站收集（例如：1. appA主動設置域B cookie，讓域B cookie獲取；2. XSS，在appA上通過javascript獲取document.cookie，并傳遞給自己的appB）。
基于cookie-session身份驗證機制的流程
1.用戶輸入登錄信息
2.服務器驗證登錄信息是否正確，如果正確就創建一個session,并把session存入數據庫
3.服務器端會向客戶端返回帶有sessionID的cookie
4.在接下來的請求中，服務器將把sessionID與數據庫中的相匹配，如果有效則處理該請求
5.如果用戶登出app，session會在客戶端和服務器端都被銷毀
基于token的身份驗證
最近幾年由于單頁app、web APIs等的興起，基于token的身份驗證開始流行。當我們談到利用token進行認證，我們一般說的就是利用JSON Web Tokens（JWTs）進行認證。雖然有不同的方式來實現token, 事實上，JWTs 已成為標準。因此在本文中將互換token與JWTs。
基于token的身份驗證是無狀態的，服務器不需要記錄哪些用戶已經登錄或者哪些JWTs已經處理。每個發送到服務器的請求都會帶上一個token,服務器利用這個token檢查確認請求的真實性。
這里可以把token理解成一張演唱會的門票。服務器(演唱會主辦方)每次只需要檢查你這張門票的有效性，不需要知道你這張門票是在哪里買的，從誰買的，什么時候買的等等。不同等級的門票可以坐的位置不同，同樣的，權限不同的用戶可以進行的操作也不同。
token通常以Bearer { JWT }的形式附加在已驗證的請求頭中，但是也可以用post請求體或者問句參數進行傳遞。
JWT
JWT是一種無狀態的鑒權機制。將用戶登錄后的一些信息（比如用戶Id）和過期時間等信息存儲在一個加密過的字符串中,當服務器收到請求的時候，進行解密并直接使用信息
JWT的組成：使用base64編碼描述jwt的頭部、使用base64編碼的payload，以及加密簽名
缺點，服務器無法像session一樣方便地管理用戶登錄狀態
JWT機制工作流程
1.用戶輸入登錄信息
2.服務器驗證登錄信息，如果正確就返回一個已簽名的token
3.這個token存儲在客戶端，最常見的是存儲在localstorage中，但是也可以存在session storage和cookie中
4.之后向服務器發送的請求都會帶上這個token
5.服務器解碼JWT，如果token是有效的則處理這個請求
6.如果用戶退出登錄，token會在客戶端銷毀，這一步與服務器無關
參考：
http://blog.leapoahead.com/2015/09/07/user-authentication-with-jwt/
https://auth0.com/blog/cookies-vs-tokens-definitive-guide/
https://my.oschina.net/biezhi/blog/490242#OSC_h2_3
