以前對認證這方面的認識一直不太深刻，不清楚為什麼需要token這種認證，為什麼不簡單使用session儲存使用者登入資訊等。最近讀了幾篇大牛的部落格才對認證機制方面有了進一步了解。
這種認證直接順應http協議的無狀態性，每次執行業務的時候，都暴力地附帶username與password引數，並將其傳送給伺服器進行驗證。儘管在伺服器端可以優雅地使用aop技術（如***或動態**）對所有controller進行前置的登入驗證。但如果每次驗證都要查資料庫的話，建立連線與查詢操作勢必會增大開銷。如果伺服器端不做任何記憶（有狀態性）處理的話，那麼這種方式就已經沒有其他辦法可以優化了。
上面已經點到，只要伺服器端稍加一些記憶處理（記錄哪些使用者登入過）即可大大優化這個過程：只需要在使用者第一次登入系統的時候，將對應的username放入乙個類似與set的資料結構中。只要登入一次（保證不退出），那麼當使用者第二次訪問controller的時候，只需要查詢set中是否有該username即可。但這種方式仍有不足，即每次還是必須要求客戶端傳username過來，否則伺服器端不知道是誰就無法判斷了。
要優雅地解決上述問題，就要得益於後來http協議**現的cookie與session技術了。當瀏覽器利用http協議訪問伺服器的時候，伺服器會為其自動建立乙個其獨有的session物件。session在基本的資料結構上類似於鍵值對map，但不同的是它還提供了若干操作方法，且可以設定時效。既然乙個瀏覽器唯一對應了乙個session，那就好辦了，使用者第一次登入驗證成功後，就可把使用者名稱寫入session中表徵當前處於該瀏覽器上的使用者已經登入，以後訪問controller只用查session中是否有username鍵即可，若有放行，若沒有則阻止。如下圖所示：
目前被眾多公司廣泛採用的是token認證，它的認證過程都是圍繞著乙個名為token字串展開的，其認證流程如下：
第一次登入
使用者攜帶username與password請求第一次登入（為保證安全性通常採用https協議傳輸）；
伺服器接收到後，查詢資料庫看使用者是否存在且密碼（md5加密後）是否匹配，若匹配，則在使用者表中查詢該使用者資訊（角色、許可權、狀態等）；
從配置檔案中讀取簽名的私鑰，並整合上一步得到的使用者資訊生成token（可採用第三方庫jwt lib）；
將token寫入cookie並重定向到前端。
登入後訪問業務
使用者攜帶從cookie（若為移動終端，可以是資料庫或檔案系統）取出的token訪問需登入及特定許可權的業務；
請求首先被認證***攔截，並獲取到傳來的token值；
根據配置檔案中的簽名私鑰，結合jwt lib進行解密與解碼；
驗證簽名是否正確（若不正確jwt會丟擲異常）、token是否過期與接收方是否是自己（由自己判斷）等。若通過則證明使用者已登入，進入許可權驗證階段；
通過許可權驗證框架（shiro、spring security等）驗證使用者是否具有訪問該業務的許可權，若有則返回相應資料。
雖然token認證優勢非常明顯，但仍然需要考慮如下問題：如何抵禦跨站指令碼攻擊（xss）、如何防範重放攻擊（replay attacks）、如何防範mitm （man-in-the-middle）攻擊等。對此本文就不再做詳細敘述了。
web認證機制
以前對認證這方面的認識一直不太深刻，不清楚為什麼需要token這種認證，為什麼不簡單使用session儲存使用者登入資訊等。最近讀了幾篇大牛的部落格才對認證機制方面有了進一步了解。這種認證直接順應http協議的無狀態性，每次執行業務的時候，都暴力地附帶username與password引數，並將其傳...
HTTP認證機制
http請求報頭 authorization http響應報頭 www authenticate http認證 基於 質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使...
HTTP認證機制
http請求報頭 authorization http響應報頭 www authenticate http認證 基於 質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使...