## 兩種認證簡介 ### 1. 有狀態認證 * 有狀態認證，以cookie-session模型為例，當客戶端第一次請求服務端的時候，服務端會返回客戶端一個唯一的標識（默認在cookie中），并保存對應的客戶端信息至sessionManager中。 * 客戶端接受到唯一標識之后，將標識保存到本地cookie中，以后的每次請求都攜帶此cookie，服務器根據此cookie標識就可以判斷請求的用戶是誰，然后查到對應用戶的信息。 * 如果session過期或者手動刪除服務端的session信息，該用戶請求將會失去認證，需要重新登錄保存session才可以再次請求受保護的資源 ### 2. 無狀態認證 * 無狀態認證，以json-web-token為例，客戶端在提交身份信息，服務端驗證身份后，根據一定的算法生成一個token令牌返回給客戶端，但服務端本身并不保存token，這樣原生就支持了分布式的特性，無需在每臺服務器都做同步。 * 客戶端接受到token后，會將令牌保存到本地，之后每次請求服務端，客戶端都需要攜帶此令牌，服務器接受到令牌進行校驗，校驗通過，以解析令牌的信息用來區別用戶。 ## 兩種認證優劣 ### 1. 有狀態認證 * 優勢：因為客戶端的信息都保存在服務端的 Session Manager 中，如果要將客戶端的認證信息取消，只需要將對應的session 信息刪除即可，及時響應，方便快捷。 * 劣勢：服務端保存著客戶端的信息，當用戶量特別多時候，服務端需要特別的內存資源；客戶端的信息在服務端中維護，如果服務端為集群的場景下，那么客戶端信息不共享，必須使用分布式 session 或者其他方案；cookie有同源策略和跨域限制，部分業務場景下cookie并不能傳遞；部分設備本身不支持cookie或者禁用cookie，還有的手機瀏覽器也不支持cookie。 ### 2. 無狀態認證 * 優勢：因為服務端不保留客戶端的任何信息，每次只需要通過特定的算法進行校驗，節省了大量存儲空間；方便水平擴容，不需要拓展服務器，也不需要進行信息同步，只要保證新的應用采用同樣的驗證算法，就可以驗證通過并獲得對應信息。 * 劣勢：當客戶端的token被盜用，或者需要手動封禁某個用戶的時候，沒辦法對此token進行操作，必須等待token失效。