基於Token的身份認證 與 基於服務器的身份認證
阿新 • • 發佈：2019-04-07
校驗 註意 共享 con ESS 壓力 not 先來 怎麽
基於Token的身份認證 與 基於服務器的身份認證
基於服務器的身份認證
在討論基於Token的身份認證是如何工作的以及它的好處之前，我們先來看一下以前我們是怎麽做的：
HTTP協議是無狀態的，也就是說，如果我們已經認證了一個用戶，那麽他下一次請求的時候，服務器不知道我是誰，我們必須再次認證
傳統的做法是將已經認證過的用戶信息存儲在服務器上，比如Session。用戶下次請求的時候帶著Session ID，然後服務器以此檢查用戶是否認證過。
這種基於服務器的身份認證方式存在一些問題：
- Sessions : 每次用戶認證通過以後，服務器需要創建一條記錄保存用戶信息，通常是在內存中，隨著認證通過的用戶越來越多，服務器的在這裏的開銷就會越來越大。
- Scalability : 由於Session是在內存中的，這就帶來一些擴展性的問題。
- CORS : 當我們想要擴展我們的應用，讓我們的數據被多個移動設備使用時，我們必須考慮跨資源共享問題。當使用AJAX調用從另一個域名下獲取資源時，我們可能會遇到禁止請求的問題。
- CSRF : 用戶很容易受到CSRF攻擊。
JWT與Session的差異
相同點是，它們都是存儲用戶信息；然而，Session是在服務器端的，而JWT是在客戶端的。
Session方式存儲用戶信息的最大問題在於要占用大量服務器內存，增加服務器的開銷。
而JWT方式將用戶狀態分散到了客戶端中，可以明顯減輕服務端的內存壓力。
Session的狀態是存儲在服務器端，客戶端只有session id；而Token的狀態是存儲在客戶端。
基於Token的身份認證是如何工作的
基於Token的身份認證是無狀態的，服務器或者Session中不會存儲任何用戶信息。
沒有會話信息意味著應用程序可以根據需要擴展和添加更多的機器，而不必擔心用戶登錄的位置。
雖然這一實現可能會有所不同，但其主要流程如下：
- 用戶攜帶用戶名和密碼請求訪問
- 服務器校驗用戶憑據
- 應用提供一個token給客戶端
- 客戶端存儲token，並且在隨後的每一次請求中都帶著它
- 服務器校驗token並返回數據
註意：
- 每一次請求都需要token
- Token應該放在請求header中
- 我們還需要將服務器設置為接受來自所有域的請求，用Access-Control-Allow-Origin: *
用Token的好處
- 無狀態和可擴展性：Tokens存儲在客戶端。完全無狀態，可擴展。我們的負載均衡器可以將用戶傳遞到任意服務器，因為在任何地方都沒有狀態或會話信息。
- 安全：Token不是Cookie。（The token, not a cookie.）每次請求的時候Token都會被發送。而且，由於沒有Cookie被發送，還有助於防止CSRF攻擊。即使在你的實現中將token存儲到客戶端的Cookie中，這個Cookie也只是一種存儲機制，而非身份認證機制。沒有基於會話的信息可以操作，因為我們沒有會話!
還有一點，token在一段時間以後會過期，這個時候用戶需要重新登錄。這有助於我們保持安全。還有一個概念叫token撤銷，它允許我們根據相同的授權許可使特定的token甚至一組token無效。
JWT與OAuth的區別
- OAuth2是一種授權框架 ，JWT是一種認證協議
- 無論使用哪種方式切記用HTTPS來保證數據的安全性
- OAuth2用在使用第三方賬號登錄的情況(比如使用weibo, qq, github登錄某個app)，而JWT是用在前後端分離, 需要簡單的對後臺API進行保護時使用。
基於Token的身份認證 與 基於服務器的身份認證