基本認證便捷靈活，但極不安全。使用者名稱和密碼都是以明文形式傳送的，也沒有採取任何措施防止對報文的篡改。安全使用基本認證的唯一方式就是將其與 ssl 配合使用。
摘要認證是另一種 http 認證協議，它與基本認證相容，但卻更為安全。摘要認證試圖修復基本認證協議的嚴重缺陷。具體來說，摘要認證進行了如下改下：
摘要認證並不是最安全的協議。摘要認證並不能滿足安全 http 事務的很多需求。對這些需求來說，使用 tls 和 https 協議更為合適一些。但摘要認證比它要取代的基本認證強大很多。
下面來看看摘要認證的工作原理（簡化版本）：
a) 客戶端請求了某個受保護文件。
b) 在客戶端能夠證明其知道密碼從而確認其身份之前，伺服器拒絕提供文件。伺服器向客戶端發起質詢，詢問使用者名稱和摘要形式的密碼。
c) 客戶端傳遞了密碼的摘要，證明它是知道密碼的。伺服器知道所有使用者的秘密，因此可以將客戶提供的摘要與伺服器自己計算得到的摘要進行比較，以驗證使用者是否知道密碼。另一方在不知道密碼的情況下，很難偽造出正確的摘要。
d) 伺服器將客戶端提供的摘要與伺服器內部計算出的摘要進行對比。如果匹配，就說明客戶端知道密碼（或者很幸運地猜中了！）。可以設定摘要函式，使其產生很多數字，讓人不可能幸運地猜中摘要。伺服器進行了匹配驗證之後，會將文件提供給客戶端——整個過程都沒有在網路上傳送密碼。
使用摘要就無需以明文形式傳送密碼了。可以只傳送密碼的摘要，而且可以確信，沒有哪個惡意使用者能輕易地從摘要中解碼出原始密碼。
但是，僅僅隱藏密碼並不能避免危險，因為即便不知道密碼，別有用心的人也可以截獲摘要，並一遍遍地重放給伺服器。摘要和密碼一樣好用。
為防止此類重放攻擊的發生，伺服器可以向客戶端傳送了乙個稱為隨機數 (nonce) 的特殊令牌，這個數會經常發生變化（可能是每毫秒，或者是每次認證都變化）。客戶端在計算摘要之前要先將這個隨機數令牌附加到密碼上去。
在密碼中加入隨機數就會使摘要隨著隨機數的每一次變化而變化。記錄下的密碼摘要只對特定的隨機數有效，而沒有密碼的話，攻擊者就無法計算出正確的摘要，這樣就可以防止重放攻擊的發生。
摘要認證要求使用隨機數，因為這個小小的重放弱點會使未隨機化的摘要認證變得和基本認證一樣脆弱。隨機數是在 www-authenticate 質詢中從伺服器傳送給客戶端。
下面是簡化的摘要認證三步握手機制：
(1) 伺服器計算出乙個隨機數。
(2) 伺服器將這個隨機數放在 www-authenticate 質詢報文中，與伺服器所支援的演算法列表一同發往客戶端。
(3) 客戶端選擇乙個演算法，計算出密碼和其他資料的摘要。
(4) 客戶端將摘要放在一條 authorization 報文中發回伺服器。如果客戶端要對伺服器進行認證，可以傳送客戶端隨機數。
(5) 伺服器接收摘要、選中的演算法以及支撐資料，計算出與客戶端相同的摘要。然後伺服器將本地生成的摘要與網路傳送過來的摘要進行比較，驗證是否匹配。如果客戶端反過來用客戶端隨機數對伺服器進行質詢，就會建立客戶端摘要。伺服器可以預先將下乙個隨機數計算出來，提前將其傳遞給客戶端，這樣下一次客戶端就可以預先傳送正確的摘要了。
普通的認證方式中，事務結束之前，每條請求都要有一次請求/質詢的需要，參見下圖 (a)。
如果客戶端事先知道下乙個隨機數是什麼，就可以取消這個請求/質詢迴圈，這樣客戶端就可以在伺服器發出請求之前，生成正確的 authorization 首部了。如果客戶端能在伺服器要求他計算 authorization 首部之前將其計算出來，就可以預先將 authorization 首部傳送給伺服器，而不用進行請求/質詢了。下圖 (b) 顯示了這種方式對效能的影響。
預授權對基本認證來說並不重要（而且很常見）。瀏覽器通常會維護一些客戶端資料庫以儲存使用者名稱和密碼。一旦使用者與某站點進行了認證，瀏覽器通常會為後繼對那個 url 的請求傳送正確的 authorization 首部。
由於摘要認證使用了隨機數技術來破壞重放攻擊，所以對摘要認證來說，預授權要稍微複雜一些。伺服器會產生任意的隨機數，所以在客戶端收到質詢之前，不一定總能判定應該傳送什麼樣的 authorization 首部。
摘要認證在保留了很多安全特性的同時，還提供了集中預授權方式。這裡列出了三種可選的方式，通過這些方式，客戶端無效等待新的 www-authenticate 質詢，就可以獲得正確的隨機數：
可以在 authentication-info 成功首部中將下乙個隨機數預先提供給客戶端。這個首部是與前一次成功認證的 200 ok 響應一同傳送的。
authentication-info: nextnonce=""有了下乙個隨機數，客戶端就可以預先發布 authorization 首部了。
儘管這種預授權機制避免了請求/質詢迴圈（加快了事務處理的速度），但實際上它也破壞了對同一臺伺服器的多條請求進行管道化的功能，因為在發布下一條請求之前，一定要收到下乙個隨機值才行。而管道化是避免延遲的一項基本技術。所以這樣可能會造成很大的效能損失。
另一種方法不是預先生成隨機數序列，而是在有限的次數內重用隨機數。比如，伺服器可能允許將某個隨機重用 5 次，或者重用 10 秒。
在這種情況下，客戶端可以隨意發布帶有 authorization 首部的請求，而且由於隨機數是事先知道的，所以還可以對請求進行管道化。隨機數過期時，伺服器要向客戶端傳送 401 unauthorized 質詢，並設定 www-authenticate:stale=true 指令：
www-authenticate: digest realm="", nonce="", stale=true
重用隨機數使得攻擊者更容易成功地實行重放攻擊。雖然這確實降低了安全性，但重用的隨機數的生存週期是可控的（從嚴格禁止重用到較長時間的重用），所以應該可以在安全和效能間找到平衡。
還可以採用時間同步的隨機數生成演算法，客戶端和伺服器可根據共享的金鑰，生成第三方無法輕易**的、相同的隨機數序列。
http摘要認證
摘要 認證步驟 1.客戶端訪問乙個受http摘要認證保護的資源。2.伺服器返回401狀態以及nonce等資訊，要求客戶端進行認證。3.客戶端將以使用者名稱，密碼，nonce值，http方法,和被請求的uri為校驗值基礎而加密 預設為 md5演算法 的摘要資訊返回給伺服器。認證必須的五個情報 real...
HTTP 基本認證，摘要認證，擴充套件HTTP認證
http請求報頭 authorization http響應報頭 www authenticate http認證 基於質詢 回應 challenge response 的認證模式。基本認證 basic authentication http1.0提出的認證方法 客戶端對於每乙個realm，通過提供使用...
http 基本認證與摘要認證
基本認證 a 客戶端 查詢 b 伺服器 質詢 c 客戶端 響應 authorization basic ynjpyw4tdg90dhk6t3ch d 伺服器 成功,返回資訊 http 1.1 200 ok基本認證的缺陷在於 賬號和密碼是明文傳送,不安全.摘要認證 a 客戶端 查詢 b 伺服器 質詢 ...