如今web服務随處可見，成千上萬的web程式被部署到公網上供使用者通路，有些系統隻針對指定使用者開放，屬于安全級别較高的web應用，他們需要有一種認證機制以保護系統資源的安全，本文将探讨五種常用的認證機制及優缺點。
HTTP協定規範中有兩種認證方式，一種是Basic認證，另外一種是Digest認證，這兩種方式都屬于無狀态認證方式，所謂無狀态即服務端都不會在會話中記錄相關資訊，用戶端每次通路都需要将使用者名和密碼放置封包一同發送給服務端，但這并不表示你在浏覽器中每次通路都要自己輸入使用者名和密碼，可能是你第一次輸入賬号後浏覽器就保留在記憶體中供後面的互動使用。先看下HTTP協定的Basic認證模式。
既然是HTTP協定規範，那其實就是限制浏覽器廠商與web容器廠商實作各自軟體時的行為限制，例如典型的一個認證互動過程是：浏覽器向web容器發送http請求封包，web容器接收到http請求封包後解析需要通路的資源，如果該資源剛好是受保護資源，web容器則向浏覽器發送認證http響應封包，浏覽器接收到封包後彈出視窗讓使用者輸入賬号及密碼，接着再次發送包含了賬号資訊的http請求封包，web容器對賬号資訊進行鑒權，通過驗證則傳回對應資源，否則重新認證。
Basic Access Authentication scheme是在HTTP1.0提出的認證方法，它是一種基于challenge/response的認證模式，針對特定的realm需要提供使用者名和密碼認證後才可通路，其中密碼使用明文傳輸。Basic模式認證過程如下：
①浏覽器發送http封包請求一個受保護的資源。
②服務端的web容器将http響應封包的響應碼設為401，響應頭部加入WWW-Authenticate: Basic realm=”myTomcat”。
③浏覽器彈出對話框讓使用者輸入使用者名和密碼，并用Base64進行編碼，實際是使用者名+冒号+密碼進行Base64編碼，即Base64(username:password)，這次浏覽器就會在HTTP封包頭部加入Authorization: Basic bXl0b21jYXQ=。
④服務端web容器擷取HTTP封包頭部相關認證資訊，比對此使用者名與密碼是否正确，是否有相應資源的權限，如果認證成功則傳回相關資源，否則再執行②，重新進行認證。
⑤以後每次通路都要帶上認證頭部。
服務端傳回的認證封包中包含了realm=”myTomcat”，realm的值用于定義保護的區域，在服務端可以通過realm将不同的資源分成不同的域，域的名稱即為realm的值，每個域可能會有自己的權限鑒别方案。
Basic認證模式有兩個明顯的缺點：①無狀态導緻每次通信都要帶上認證資訊，即使是已經認證過的資源；②傳輸安全性不足，認證資訊用Base64編碼，基本就是明文傳輸，很容易對封包截取并盜用認證資訊。
HTTP協定規範的另一種認證模式是Digest模式，在HTTP1.1時被提出來，它主要是為了解決Basic模式安全問題，用于替代原來的Basic認證模式，Digest認證也是采用challenge/response認證模式，基本的認證流程比較類似，整個過程如下：
②服務端的web容器将http響應封包的響應碼設為401，響應頭部比Basic模式複雜，WWW-Authenticate: Digest realm=”myTomcat”,qop="auth",nonce="xxxxxxxxxxx",opaque="xxxxxxxx" 。其中qop的auth表示鑒别方式；nonce是随機字元串；opaque服務端指定的值，用戶端需要原值傳回。
③浏覽器彈出對話框讓使用者輸入使用者名和密碼，浏覽器對使用者名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合後進行MD5運算，把計算得到的摘要資訊發送給服務端。請求頭部類似如下，Authorization: Digest username="xxxxx",realm="myTomcat",qop="auth",nonce="xxxxx",uri="xxxx",cnonce="xxxxxx",nc=00000001,response="xxxxxxxxx",opaque="xxxxxxxxx" 。其中username是使用者名；cnonce是用戶端生成的随機字元串；nc是運作認證的次數；response就是最終計算得到的摘要。
④服務端web容器擷取HTTP封包頭部相關認證資訊，從中擷取到username，根據username擷取對應的密碼，同樣對使用者名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合進行MD5運算，計算結果和response進行比較，如果比對則認證成功并傳回相關資源，否則再執行②，重新進行認證。
其實通過雜湊演算法對通信雙方身份的認證十分常見，它的好處就是不必把具備密碼的資訊對外傳輸，隻需将這些密碼資訊加入一個對方給定的随機值計算哈希值，最後将哈希值傳給對方，對方就可以認證你的身份。Digest思想同樣采如此，用了一種nonce随機數字元串，雙方約好對哪些資訊進行哈希運算即可完成雙方身份的驗證。Digest模式避免了密碼在網絡上明文傳輸，提高了安全性，但它仍然存在缺點，例如認證封包被攻擊者攔截到攻擊者可以擷取到資源。
上面介紹的兩種模式都屬于HTTP協定規範範疇，由于它的規範使得很多東西無法自定義，例如登入視窗、錯誤展示頁面。是以需要另外一種模式提供更加靈活的認證，也就是基于Form的認證模式，各種語言體系的web容器都可以實作各自的Form模式，這裡隻介紹java體系的Form認證模式：
Form模式的認證流程如下：
②服務端的web容器判斷此uri為受保護資源，于是将請求重定向到自定義的登陸頁面上，例如login.html頁面，可以自定義登陸頁面的樣式，但要遵守的約定是表單的action必須以j_security_check結尾，即<form action='xxxxxx/j_security_check' method='POST'>。使用者名和密碼輸入框元素的name必須為'j_username' 和'j_password'。
③浏覽器展示自定義的登陸頁面讓使用者輸入使用者名和密碼，然後送出表單。
④服務端web容器擷取表單的使用者名和密碼，比對此使用者名與密碼是否正确，是否有相應資源的權限，如果認證成功則傳回相關資源，否則再執行②，重新進行認證。
⑤後面在同個會話期間的通路都不用再進行認證，因為認證的結果已經儲存在服務端的session裡面。
Form模式跳出了HTTP規範提供了自定義的更加靈活的認證模式，由于每種語言都可以自己定義實作自己的Form模式，是以它沒有一個通用的标準，而且它也存在密碼明文傳輸安全問題。
Spnego模式是一種由微軟提出的使用GSS-API接口的認證模式，它擴充了Kerberos協定，在了解Spnego協定之前必須先了解Kerberos協定，Kerberos協定主要解決身份認證及通信密鑰協商問題，它大緻的工作流程如下：
①用戶端根據自己使用者名向密鑰分發中心KDC的身份認證服務AS請求TGS票證。
②AS生成一個TGS票證、查詢對應使用者的密碼，然後通過使用者密碼将TGS票證加密，響應給用戶端。
③用戶端通過使用者密碼解密TGS票證，如果密碼正确就能擷取到TGS票證，然後用TGS票證去票證授予服務TGS請求服務票證。
④TGS将服務票證響應給用戶端。
⑤用戶端使用服務票證去通路某服務，服務驗證服務票據是否合法。
⑥驗證通過，開始通信。
在了解了Kerberos協定後，我們再來看看Spnego的認證過程是怎樣的。由于spnego擴充自kerberos協定，認證的核心流程一樣，隻是在浏覽器與web伺服器之間的http通信過程中嵌入認證流程。如下圖：
①用戶端浏覽器向web伺服器發送http請求。
②伺服器傳回401狀态碼，響應頭部加上 WWW-Authenticate:Negotiate。
③使用者通過浏覽器輸入使用者名向AS請求TGS票證。
④AS生成TGS票證，然後查詢使用者密碼并用此密碼加密TGS票證，傳回浏覽器。
⑤浏覽器使用使用者密碼解密出TGS票證，并向TGS服務發起請求。
⑥TGS服務生成服務票證響應給浏覽器。
⑦浏覽器将服務票證封裝到SPNEGO token中，并發送給web伺服器。
⑧伺服器解密出使用者名及服務票證，将票證發往TGS服務驗證。
⑨通過驗證，開始通信。
可以看到Spnego模式提供了更加強大的安全認證，它将認證子產品獨立出來，雖然結構複雜了，但這樣可以為所有應用提供認證功能，例如它可以很容易實作多個系統之間的單點登入。
SSL模式是基于SSL通信的一種認證模式，它的大體流程是這樣的：用戶端與伺服器之間通過SSL協定建立起SSL通道，這個過程比較複雜，涉及到用戶端服務端證書互互相動驗證，協商通信密鑰等過程，細節可以前往SSL章節閱讀。完成整個SSL通道建立後才是認證的核心步驟，如下圖，
①首先擷取用戶端證書檔案，這個由于在SSL協定期間已經發送到服務端，是以可以直接從記憶體中擷取，然後解析證書檔案得到證書辨別。
②通過這個證書辨別去存放使用者資訊的地方查找出對應用戶端證書使用者的相關資訊。
③檢查此使用者是否有相關資源的權限，如果驗證通過則傳回請求相關資源。
SSL模式也提供了高安全認證，它隻對頒發的用戶端證書個體信任，可用于服務端與服務端之間的通信，也可以用在浏覽器與web伺服器之間通信，這時必須使用https協定，因為它必須走SSL協定通道才能完成認證流程。
本文介紹了五種常見的安全認證機制，他們各自有各自的優缺點，在實際使用中根據具體的場景選擇不同的認證機制。
==========廣告時間==========
鄙人的新書《Tomcat核心設計剖析》已經在京東預售了，有需要的朋友可以到 https://item.jd.com/12185360.html 進行預定。感謝各位朋友。
=========================