摘要：最近讀了幾篇大牛的博客才對認證機制方面有了進一步了解。盡管在服務器端可以優雅地使用技術如攔截器或動態代理對所有進行前置的登錄驗證。認證方式比較支持問題和其實是緊密相聯的。第三方授權問題采用傳統認證方式，若要訪問業務，一定要先登錄。

以前對認證這方面的認識一直不太深刻，不清楚為什么需要token這種認證，為什么不簡單使用session存儲用戶登錄信息等。最近讀了幾篇大牛的博客才對認證機制方面有了進一步了解。

Basic Auth

這種認證直接順應HTTP協議的無狀態性，每次執行業務的時候，都暴力地附帶username與password參數，并將其發送給服務器進行驗證。盡管在服務器端可以優雅地使用AOP技術（如攔截器或動態代理）對所有controller進行前置的登錄驗證。但如果每次驗證都要查數據庫的話，創建連接與查詢操作勢必會增大開銷。如果服務器端不做任何記憶（有狀態性）處理的話，那么這種方式就已經沒有其他辦法可以優化了。

Cookie/Session Auth

上面已經點到，只要服務器端稍加一些記憶處理（記錄哪些用戶登錄過）即可大大優化這個過程：只需要在用戶第一次登錄系統的時候，將對應的username放入一個類似與Set的數據結構中。只要登錄一次（保證不退出），那么當用戶第二次訪問controller的時候，只需要查詢Set中是否有該username即可。但這種方式仍有不足，即每次還是必須要求客戶端傳username過來，否則服務器端不知道是誰就無法判斷了。
要優雅地解決上述問題，就要得益于后來HTTP協議中出現的Cookie與Session技術了。當瀏覽器利用HTTP協議訪問服務器的時候，服務器會為其自動創建一個其獨有的session對象。session在基本的數據結構上類似于鍵值對Map，但不同的是它還提供了若干操作方法，且可以設置時效。既然一個瀏覽器唯一對應了一個session，那就好辦了，用戶第一次登錄驗證成功后，就可把用戶名寫入session中表征當前處于該瀏覽器上的用戶已經登錄，以后訪問controller只用查session中是否有username鍵即可，若有放行，若沒有則阻止。如下圖所示：

Token Auth

目前被眾多公司廣泛采用的是token認證，它的認證過程都是圍繞著一個名為token字符串展開的，其認證流程如下：

第一次登錄
用戶攜帶username與password請求第一次登錄（為保證安全性通常采用HTTPS協議傳輸）；
服務器接收到后，查詢數據庫看用戶是否存在且密碼（MD5加密后）是否匹配，若匹配，則在用戶表中查詢該用戶信息（角色、權限、狀態等）；
從配置文件中讀取簽名的私鑰，并整合上一步得到的用戶信息生成token（可采用第三方庫JWT lib）；
將token寫入cookie并重定向到前端。
登錄后訪問業務
用戶攜帶從cookie（若為移動終端，可以是數據庫或文件系統）取出的token訪問需登錄及特定權限的業務；
請求首先被認證攔截器攔截，并獲取到傳來的token值；
根據配置文件中的簽名私鑰，結合JWT lib進行解密與解碼；
驗證簽名是否正確（若不正確JWT會拋出異常）、token是否過期與接收方是否是自己（由自己判斷）等。若通過則證明用戶已登錄，進入權限驗證階段；
通過權限驗證框架（shiro、spring security等）驗證用戶是否具有訪問該業務的權限，若有則返回相應數據。

1.cookie支持問題
session和cookie其實是緊密相聯的。瀏覽器與服務器首次建立連接的時候，服務器會自動生成一個會話號sid，并寫入響應報文的首部字段中，返回給客戶端讓其存入cookie。之后每次的HTTP請求報文中均會在首部寫入cookie中的sid，服務器接收到后根據sid取出對應session，再進一步根據username鍵是否存在判斷登錄與否。
可以看出cookie/session認證要求客戶端必須支持cookie技術，但很顯然，客戶端并不是只能為瀏覽器，還可以是PC桌面、移動終端等其它平臺，對于這些平臺，我們無法保證他們都能支持cookie技術。而token認證只認token這個字符串值，至于前端是瀏覽器采用cookie存的token還是Android終端用數據庫存的token都無所謂，只要拿到token值即可進行驗證。
2.session共享問題
session是無法在多臺服務器之間共享的，特別在分布式部署環境（即多臺部署了同一系統的Web服務器集群）下將帶來很多同步、一致性問題。比如下面這個場景：
用戶請求登錄，HTTP請求被轉發到了服務器A，在A上完成認證后將登錄狀態記錄到了session；
用戶后續請求其他需登錄的業務，HTTP請求被轉發到了非A的服務器上，這時由于這些服務器上的session并非A上的session，所以其上就沒有登錄狀態記錄，所以業務操作將被拒絕！
很顯然這時采用cookie/session認證就很棘手了，需要自己去維護同步、狀態一致等問題。而token根本不會依賴session，所有服務器都是一致地采用私鑰+解密算法分析簽名的正確性。
3 時間/空間開銷問題
如果session不僅是要存儲用戶名，還要存儲時效時間、登錄時間等各種狀態信息（特別是大型系統），那么一旦登錄的用戶數激增，服務器的內存消耗也將急劇增大。而token認證是完全將狀態存入了token值中，再利用加解密算法將狀態取出，用時間復雜度換取了空間復雜度，內存開銷大大減小，時間效率有降低。
4 第三方授權問題
采用傳統認證方式，若要訪問業務，一定要先登錄。假如這時一個第三方應用希望獲取該用戶在本系統的一些資源（如頭像、昵稱、簽名等），則一定要先接受登錄攔截器認證才可放行，這時如果第三方應用也通過用戶名+密碼登錄的形式來獲取信息的話，勢必會暴露用戶在本系統的信息，很不安全！
而一種更巧妙的做法是，先記錄第三方應用的AppID與其url地址，然后跳轉到本系統登錄頁面進行登錄，認證成功后，經本系統的認證服務器生成access_token，攜帶該參數并重定向到url地址所在頁面。此后第三方應用即可憑借該access_token的權限范圍，訪問所需的本系統的資源。
可以看出，無論是本系統自己憑借token訪問自己的資源，還是第三方應用憑借access_token訪問本系統資源，依靠的都是token這個憑據，走的都是統一的一套流程，而傳統方式，需要額外寫一套，可維護性很不好。關于第三方認證文章可以參考理解Ouath2.0。

雖然token認證優勢非常明顯，但仍然需要考慮如下問題：如何抵御跨站腳本攻擊（XSS）、如何防范重放攻擊（Replay Attacks）、如何防范MITM （Man-In-The-Middle）攻擊等。對此本文就不再做詳細敘述了。