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

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

Basic Auth

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

Cookie/Session Auth

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

Token Auth

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

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

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

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