基本認證:

// (a)客戶端:查詢
GET /cgi-bin/checkout?cart=17854 HTTP/1.1// (b)服務器:質詢
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Shopping Cart"// (c)客戶端:響應
GET /cgi-bin/checkout?cart=17854 HTTP/1.1
Authorization: Basic YnJpYW4tdG90dHk6T3ch// (d)服務器:成功,返回信息
HTTP/1.1 200 OK

基本認證的缺陷在于:賬號和密碼是明文發送,不安全.
摘要認證:

// (a)客戶端:查詢
GET /cgi-bin/checkout?cart=17854 HTTP/1.1// (b)服務器:質詢
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digestrealm="Shopping Cart"qop="auth,auth-int"nonce="66C4EF58DA7CB956BD04233FBB64E0A4"// (c)響應
GET /cgi-bin/checkout?cart=17854 HTTP/1.1
Authorization: Digestusername="bri"realm="Shopping Cart"nonce="66C4EF58DA7CB956BD04233FBB64E0A4"uri="/cgi-bin/checkout?cart=17854"qop="auth"nc=0000001,cnonce="CFA9207102EA210FFC1120F6001110D073"response="E483C94FOB3CA29109A7BA83D10FE519"// (d)成功
HTTP/1.1 200 OK
Authorization-Info: nextnonce="29FE72D109C7EF23841AB914F0C3B831"qop= 0auth0rspauth="89F5A4CE6FA932F6C4DA120CEB754290"cnonce="CFA9207102EA210EA210FFC1120F6001110D073"....

摘要認證的3個組件:

// *摘要由以下3個組件計算出來:
// 1.由單向散列函數H(d)和摘要KD(s,d)組成的一對函數,其中s表示密碼,d表示數據
// 2.一個包含了安全信息的數據塊,包括密碼,稱為A1
// 3.一個包含了請求報文中非保密屬性的數據塊,稱為A2

安全性相關的數據(A1)

// A1是密碼和受保護信息的產物,它包含有用戶名、密碼、保護域和隨機數等內容

與報文有關的數據(A2)

// 數據庫A2表示的是與報文自身有關的信息,比如URL、請求方法和報文實體的主體部分
// A2有助于防止方法、資源或報文被篡改

摘要認證會話

// 客戶端在響應保護空間的WWW-Authenticate質詢時(請求賬號、密碼信息),會啟動一個此保護空間的認證會話
// 在客戶端收到另一條來自保護空間的任意一臺服務器的WWW-Authenticate質詢之前,認證會話會一直持續

預授權

// 在普通的認證方式中,事務結束之前,每條請求都要有一次 請求/質詢 的循環
// 如果客戶端事先知道下一個隨機數是什么,就可以取消這個 請求/質詢 循環
// 這樣客戶端就可以在服務器發出請求之前,生成正確的Authorization首部了.

對稱認證

// RFC 2617擴展了摘要認證機制,允許客戶端對服務器進行認證.
// 通過提供客戶端隨機數來實現的.
// 它是可選的.

增強保護質量

// 可以在三種摘要首部中提供qop(保護質量)字段:WWW-authenticate、Authorization和Authentication-Info
// 通過qop字段,客戶端和服務器可以對不同類型及質量的保護進行協商.

多重質詢

// 服務器可以對某個資源發起多重質詢.如:服務器不了解客戶端的能力,可以既提供基本認證質詢,又提供摘要認證質詢
// 客戶端在面對多重質詢時,必須以它所支持的最強的質詢機制來應答

差錯處理

// 在摘要認證中,如果某個指令或其值使用不當,或者缺少某個必要指令,就應該使用響應400 Bad Request
// 如果請求的摘要不匹配,就應該記錄一次登錄失敗.某客戶端連續多次失敗可能說明有攻擊者正在猜測密碼

保護空間

// 閾值,與被訪問服務器的標準根URL結合在一起,定義了保護空間
// 通過域可以將服務器上的受保護資源劃分為一組保護空間,每個空間都有自己的認證機制 和/或 授權數據庫

參考《HTTP權威指南》P308~P318