寫在前面：本文僅供個人學習使用，如有侵權，請聯系刪除。文章中所用圖片絕大多數來源于《圖解HTTP》，請讀者支持原版。

文章目錄

• • 8.1何為認證
  • 8.2 BASIC認證
  • 8.3 DIGEST認證
  • 8.4 SSL客戶端認證
  • • 8.4.1 SSL客戶端認證的認證步驟
    • 8.4.2 SSL客戶端認證采用雙因素認證
    • 8.4.3SSL客戶端認證必要的費用
  • 8.5 基于表單的認證
  • • 8.5.1 認證多半為基于表單認證
    • 8.5.2 Session管理及Cookie應用

某些Web頁面只想讓特定的人瀏覽，或者干脆僅本人可見。為達到這個目的，必不可少的就是認證功能。下面我們一起來學習一下認證機制。

8.1何為認證

核對的信息有密碼、動態令牌、數字證書、生物認證、IC卡等。

HTTP使用的認證方式

HTTP/1.1使用的認證方式如下

• BASIC認證（基本認證）
• DIGEST認證（摘要認證）
• SSL客戶端認證
• FormBase認證（基于表單認證）

8.2 BASIC認證

BASIC認證（基本認證）是從HTTP/1.0就定義的認證方式。即便是現在仍有一部分的網站會使用這種認證方式。是Web服務器與通信客戶端之間進行的認證方式。

BASIC認證雖然采用Base64編碼方式，但這不是加密處理。不需要任何附加信息即可對其解碼。換言之，由于明文解碼后就是用戶ID和密碼，在HTTP等非加密通信的線路上進行BASIC認證的過程中，如果被人竊聽，被盜的可能性極高。

另外，除此之外想再進行一次BASIC認證時，一般的瀏覽器卻無法實現認證注銷操作，這也是問題之一。

BASIC認證使用上不夠便捷靈活，且達不到多數Web網站期望的安全性等級，因此它并不常用。

8.3 DIGEST認證

為彌補BASIC認證存在的缺點，從HTTP/1.1起就有了DIGEST認證。DIGEST認證同樣使用質詢/響應的方式(challenge/response)，但不會像BASIC認證那樣直接發送明文密碼。

所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接著使用從另一方那接收到的質詢碼計算生成的響應碼。最后將響應碼返回給對方進行認證的方式。

因為發送給對方的只是相應摘要及由質詢碼產生的計算結果，所以比起BASIC認證，密碼泄露的可能性就降低了。

DIGEST認證提供了高于 BASIC認證的安全等級，但是和HTTPS的客戶端認證相比仍然很弱。DIGEST認證提供方式密碼被竊聽的保護機制，但并不存在防止用戶偽裝的保護機制。

DIGEST認證和BASIC認證一樣，使用上不那么靈活便捷，且仍然達不到多數Web網站對高度安全等級的追求標準。因此它的適用范圍也有所受限。

8.4 SSL客戶端認證

從使用用戶ID和密碼的認證方式方面來講，只要兩者的內容正確，即可認證是本人的行為。但如果用戶ID和密碼被盜，就很有可能被第三者冒充。利用SSL客戶端認證則可以避免該情況的發生。

SSL客戶端認證是借由HTTPS的客戶端證書完成認證的方式。憑借客戶端證書認證，服務器可確認訪問是否來自已經登錄的客戶端。

8.4.1 SSL客戶端認證的認證步驟

為達到SSL客戶端認證的目的，需要事先將客戶端證書分發給客戶端，且客戶端必須安裝此證書。

步驟1： 接收到需要認證資源的請求，服務器會發送Certificate Request 報文，要求客戶端提供客戶端證書。

步驟2：用戶選擇將發送的客戶端證書后，客戶端會把客戶端證書信息以Client Certificate 報文方式發送給服務器。

步驟3：服務器驗證客戶端證書，驗證通過后方可領取證書內客戶端的公開密鑰，然后開始HTTPS加密通信。

8.4.2 SSL客戶端認證采用雙因素認證

在多數情況下，SSL客戶端認證不會僅依靠證書完成認證，一般會和基于表單認證組合形成一種雙因素認證(Two-factor anthentication) 來使用。所謂雙因素認證就是指，認證過程中不僅需要密碼這一個因素，還需要申請認證者提供其他持有信息，從而作為另一個因素，與其組合使用的認證方式。

換言之，第一個認證因素的SSL客戶端證書用來認證客戶端計算機，另一個認證因素的密碼則用來確定這是用戶本人的行為。

通過雙因素認證后，就可以確認是用戶本人正在使用匹配正確的計算機訪問服務器。

8.4.3SSL客戶端認證必要的費用

使用SSL客戶端認證需要用到客戶端證書。而客戶端證書需要支付一定費用才能使用。

這里提到的費用是指，從認證機構購買客戶端證書的費用，以及服務器運營者為保證自己搭建的認證機構安全運行所產生的費用。

8.5 基于表單的認證

基于表單的認證方法并不是在HTTP協議中定義的。客戶端會向服務器上的Web應用程序發送登錄信息(Credential) ，按登錄信息的驗證結果認證。

多數情況下，輸入已事先登錄的用戶ID和密碼等登陸信息后，發送給Web應用程序，基于認證結果來決定認證是否成功。

8.5.1 認證多半為基于表單認證

由于使用上的便利性及安全性問題，HTTP協議標準提供的BASIC 和DIGEST認證幾乎不怎么使用。另外，SSL客戶端認證雖然具有高度的安全等級，但因為導入及維持費用等問題，還尚未普及。

對于Web網站的認證功能，能夠滿足其安全使用級別的標準規范并不存在，所以只好使用由Web應用程序各自實現基于表單的認證方式。

8.5.2 Session管理及Cookie應用

基于表單認證的標準規范尚未有定論，一般會使用Cookie來管理Session(會話)。

基于表單認證本身是通過服務器端的Web應用，將客戶端發送過來的用戶ID和密碼與之前登陸過的信息做匹配來進行認證的。

但鑒于HTTP是無狀態協議，之前已認證成功的用戶狀態無法通過協議層面保存下來。即，無法實現狀態管理，因此即使當該用戶下一次繼續訪問，也無法區分他與其他用戶。 于是，我們會使用Cookie來管理Session，以彌補HTTP協議中不存在的狀態管理功能。

步驟1： 客戶端把用戶ID和密碼等登錄信息放入報文的實體部分，通常是以POST方法把請求發送給服務器。而這時，會使用HTTPS通信來進行HTML表單畫面的顯示和用戶輸入數據的發送。

步驟2：服務器會發放用以識別用戶的Session ID。通過驗證從客戶端發送過來的登錄信息進行身份認證，然后把用戶的認證狀態與Session ID綁定后記錄在服務器端。

步驟3：客戶端接收到從服務器端發來的Session ID后，會將其作為Cookie保存在本地。下次向服務器發送請求時，瀏覽器會自動發送Cookie，所以Session ID也隨之發送到服務器。服務器端可通過驗證接收到的Session ID識別用戶和其認證狀態。

總結

以上是生活随笔為你收集整理的《图解HTTP》读书笔记--第8章 确认访问用户身份的认证的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。