在HTTP協(xié)議進行通信的過程中，HTTP協(xié)議定義了基本認證過程以允許HTTP服務器對WEB瀏覽器進行用戶身份證的方法，當一個客戶端向HTTP服務 器進行數(shù)據(jù)請求時，如果客戶端未被認證，則HTTP服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證，以決定用戶是否合法。
客戶端在接收到HTTP服務器的身份認證要求后，會提示用戶輸入用戶名及密碼，然后將用戶名及密碼以BASE64加密，加密后的密文將附加于請求信息中， 如當用戶名為anjuta，密碼為：123456時，客戶端將用戶名和密碼用“：”合并，并將合并后的字符串用BASE64加密為密文，并于每次請求數(shù)據(jù) 時，將密文附加于請求頭（Request Header）中。
HTTP服務器在每次收到請求包后，根據(jù)協(xié)議取得客戶端附加的用戶信息（BASE64加密的用戶名和密碼），解開請求包，對用戶名及密碼進行驗證，如果用 戶名及密碼正確，則根據(jù)客戶端請求，返回客戶端所需要的數(shù)據(jù);否則，返回錯誤代碼或重新要求客戶端提供用戶名及密碼。
整個交互過程如下（模擬個登錄GOOGLE首頁的過程，并假設登錄GOOGLE需要認證）：
1,客戶端向服務器請求數(shù)據(jù)，請求的內(nèi)容可能是一個網(wǎng)頁或者是一個其它的MIME類型，此時，假設客戶端尚未被驗證，則客戶端提供如下請求至服務器：
Get /index.html HTTP/1.0
Host:www.google.com
這段信息表明，客戶端向主機www.google.com請求其位于根目錄下的index.html網(wǎng)頁，使用http1.0協(xié)議。
2,服務器向客戶端發(fā)送驗證請求代碼401,服務器返回的數(shù)據(jù)大抵如下：
HTTP/1.0 401 Unauthorised
Server: SokEvo/1.0
WWW-Authenticate: Basic realm="google.com"
Content-Type: text/html
Content-Length: xxx
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
</HEAD>
<BODY><H1>401 Unauthorised.</H1></BODY>
</HTML>
3,當符合http1.0或1.1規(guī)范的客戶端（如IE，F(xiàn)IREFOX）收到401返回值時，將自動彈出一個登錄窗口，要求用戶輸入用戶名和密碼。
4,用戶輸入用戶名和密碼后，將用戶名及密碼以BASE64加密方式加密，并將密文放入前一條請求信息中，則客戶端發(fā)送的第一條請求信息則變成如下內(nèi)容：
Get /index.html HTTP/1.0
Host:www.google.com
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxx
注：xxxx....表示加密后的用戶名及密碼。
5,服務器收到上述請求信息后，將Authorization字段后的用戶信息取出、解密，將解密后的用戶名及密碼與用戶數(shù)據(jù)庫進行比較驗證，如用戶名及密碼正確，服務器則根據(jù)請求，將所請求資源發(fā)送給客戶端：
HTTP/1.0 200 OK
Server: www.google.com/http1.0
Content-Type: text/html
Content-Length: xxxx
<html>
網(wǎng)頁內(nèi)容
</html>
如用戶名及密碼不正確，請返回第2步，重新向客戶端發(fā)送用戶驗證請求。
6,在以后的整個通信會話中，客戶端均會在請求包中附加入加密后的用戶信息。
HTTP基本認證的目標是提供簡單的用戶驗證功能，其認證過程簡單明了，適合于對安全性要求不高的系統(tǒng)或設備中，如大家所用路由器的配置頁面的認證，幾乎 都采取了這種方式。其缺點是沒有靈活可靠的認證策略，如無法提供域（domain或realm）認證功能，另外，BASE64的加密強度非常低，可以說僅 能防止sohu的搜索把它搜到了。當然，HTTP基本認證系統(tǒng)也可以與SSL或者Kerberos結(jié)合，實現(xiàn)安全性能較高（相對）的認證系統(tǒng)
