寫在前面：本文僅供個人學(xué)習(xí)使用，如有侵權(quán)，請聯(lián)系刪除。文章中所用圖片絕大多數(shù)來源于《圖解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應(yīng)用

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

8.1何為認證

核對的信息有密碼、動態(tài)令牌、數(shù)字證書、生物認證、IC卡等。

HTTP使用的認證方式

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

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

8.2 BASIC認證

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

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

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

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

8.3 DIGEST認證

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

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

因為發(fā)送給對方的只是相應(yīng)摘要及由質(zhì)詢碼產(chǎn)生的計算結(jié)果，所以比起B(yǎng)ASIC認證，密碼泄露的可能性就降低了。

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

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

8.4 SSL客戶端認證

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

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

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

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

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

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

步驟3：服務(wù)器驗證客戶端證書，驗證通過后方可領(lǐng)取證書內(nèi)客戶端的公開密鑰，然后開始HTTPS加密通信。

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

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

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

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

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

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

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

8.5 基于表單的認證

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

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

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

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

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

8.5.2 Session管理及Cookie應(yīng)用

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

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

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

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

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。