傳統(tǒng)的session認證
我們知道嘿歌，http協(xié)議本身是一種無狀態(tài)的協(xié)議站故，而這就意味著如果用戶向我們的應用提供了用戶名和密碼來進行用戶認證屯阀，那么下一次請求時宪巨，用戶還要再一次進行用戶認證才行，因為根據(jù)http協(xié)議对竣，我們并不能知道是哪個用戶發(fā)出的請求庇楞，所以為了讓我們的應用能識別是哪個用戶發(fā)出的請求，我們只能在服務器存儲一份用戶登錄的信息否纬，這份登錄信息會在響應時傳遞給瀏覽器吕晌，告訴其保存為cookie,以便下次請求時發(fā)送給我們的應用，這樣我們的應用就能識別請求來自哪個用戶了,這就是傳統(tǒng)的基于session認證临燃。
但是這種基于session的認證使應用本身很難得到擴展睛驳，隨著不同客戶端用戶的增加壁拉，獨立的服務器已無法承載更多的用戶，而這時候基于session認證應用的問題就會暴露出來.
基于session認證所顯露的問題
Session: 每個用戶經(jīng)過我們的應用認證之后柏靶，我們的應用都要在服務端做一次記錄弃理，以方便用戶下次請求的鑒別，通常而言session都是保存在內(nèi)存中屎蜓，而隨著認證用戶的增多痘昌，服務端的開銷會明顯增大。
擴展性: 用戶認證之后炬转，服務端做認證記錄辆苔，如果認證的記錄被保存在內(nèi)存中的話，這意味著用戶下次請求還必須要請求在這臺服務器上,這樣才能拿到授權(quán)的資源扼劈，這樣在分布式的應用上驻啤，相應的限制了負載均衡器的能力。這也意味著限制了應用的擴展能力荐吵。
CSRF: 因為是基于cookie來進行用戶識別的, cookie如果被截獲骑冗，用戶就會很容易受到跨站請求偽造的攻擊。
基于token的鑒權(quán)機制
基于token的鑒權(quán)機制類似于http協(xié)議也是無狀態(tài)的先煎，它不需要在服務端去保留用戶的認證信息或者會話信息贼涩。這就意味著基于token認證機制的應用不需要去考慮用戶在哪一臺服務器登錄了，這就為應用的擴展提供了便利薯蝎。
流程上是這樣的：
用戶使用用戶名密碼來請求服務器
服務器進行驗證用戶的信息
服務器通過驗證發(fā)送給用戶一個token
客戶端存儲token遥倦，并在每次請求時附送上這個token值
服務端驗證token值，并返回數(shù)據(jù)
這個token必須要在每次請求時傳遞給服務端占锯，它應該保存在請求頭里袒哥， 另外，服務端要支持CORS(跨來源資源共享)策略消略，一般我們在服務端這么做就可以了Access-Control-Allow-Origin: *堡称。
那么我們現(xiàn)在回到JWT的主題上。
JWT的構(gòu)成
第一部分我們稱它為頭部（header),第二部分我們稱其為載荷（payload, 類似于飛機上承載的物品)疑俭，第三部分是簽證（signature).
