基礎(chǔ)認證(Basic)
說直白點，認證就是讓訪問服務(wù)的人提供用戶名和密碼萍摊，然后對用戶名和密碼做校驗挤茄。
http的質(zhì)詢/響應(yīng)認證框架
客戶端和服務(wù)器的質(zhì)詢/響應(yīng)認證過程：
- 客戶端發(fā)送請求；
- 服務(wù)器收到請求后冰木，判斷如果請求的資源需要認證穷劈，則返回401狀態(tài)，并在response headers中加入WWW-Authenticate頭部踊沸，要求客戶端帶上認證信息以后再發(fā)一次請求歇终；
- 客戶端收到401返回信息后，重新向服務(wù)器發(fā)送請求逼龟，并在request headers中加入Authoriaztion頭部评凝，用來說明認證的用戶名、密碼腺律、算法等信息奕短；
- 服務(wù)器再次收到請求后宜肉，判斷認證信息無誤，返回200翎碑，并在response headers中加入Authorization-Info頭部崖飘。
借用http權(quán)威指南中一圖來說明認證過程：
安全域
服務(wù)器第一次返回中WWW-Authenticate頭部中包含realm參數(shù)，作用為標(biāo)識訪問資源的安全域杈女。服務(wù)器對不同數(shù)據(jù)區(qū)域可以設(shè)置不同的訪問權(quán)限，安全域字段的作用相當(dāng)于告訴客戶端要訪問的資源屬于服務(wù)器眾多區(qū)域中的那一片區(qū)域里吊圾。
基礎(chǔ)認證
WWW-Authenticate頭部中的Basic指的就是基礎(chǔ)認證（另外一個Digest指的是另一種認證方式：摘要認證达椰，詳見后文）。
Basic Auth超級簡單项乒，客戶端在輸入用戶名密碼后發(fā)送請求啰劲，瀏覽器會用一個冒號“：”將用戶名和密碼連接起來，然后做一下Base64編碼（關(guān)于Base64說明詳見http://blog.sina.com.cn/s/blog_87bd61ee0102wwfy.html）檀何，就直接把這個編碼后的字符串放到Authorization頭部里發(fā)給服務(wù)器了蝇裤。
代理認證
服務(wù)器可以委托代理服務(wù)器提供對內(nèi)部資源的統(tǒng)一訪問控制，即代理認證频鉴。
代理認證的步驟與服務(wù)器認證相同栓辜。但首部的狀態(tài)碼有所不同。
摘要認證(Digest)
摘要認證利用摘要算法（如MD5）對重要數(shù)據(jù)做不可逆編碼垛孔，來防止惡意截獲信息后獲取敏感內(nèi)容藕甩。
摘要認證的握手機制
客戶端和服務(wù)器的質(zhì)詢/響應(yīng)認證過程：
- 客戶端發(fā)送請求；
- 服務(wù)器收到請求后會生成一個隨機數(shù)nonce（見下文隨機數(shù)選擇）放在WWW-Authenticate頭部周荐，返回401狀態(tài)狭莱。如果要求增強保護質(zhì)量（QoP，可對實體主體做完整性校驗）概作，則將支持的QoP屬性也放在WWW-Authenticate頭部腋妙。
- 客戶端選擇一個算法（auth或者auth-int），計算出密碼和其他數(shù)據(jù)的摘要讯榕，將摘要(response)和算法(qop)放在Authorization頭部中骤素。如果客戶端還要對服務(wù)器進行認證，則生成客戶端隨機數(shù)(cnonce)愚屁、隨機數(shù)生成次數(shù)(nc)也放在Authorization中發(fā)送服務(wù)器谆甜。
- 服務(wù)器收到算法及支撐數(shù)據(jù)（請求方法、請求uri集绰、服務(wù)器隨機數(shù)等）规辱，計算出摘要，與客戶端摘要進行比較栽燕，驗證是否匹配罕袋。另外如果客戶端發(fā)送cnonce改淑，服務(wù)器會再生成一個隨機數(shù)(nextnonce)出來，然后根據(jù)nextnonce浴讯、cnonce朵夏、實體主體等等生成應(yīng)答摘要(rspauth)，加到Authorization-Info頭部中榆纽，返回客戶端仰猖。
- 客戶端收到返回后，再算出摘要奈籽，與服務(wù)器返回的rspauth比較饥侵，驗證是否匹配。后如果還要發(fā)送請求衣屏，重復(fù)3躏升、4、5步驟狼忱。
摘要算法
（1）算法基礎(chǔ)：
- H(v1) = MD5(v1); 將v1進行MD5編碼
- KD(v1, v2) = MD5(v1 : v2); 將v1和v2用冒號”:”連接后進行MD5編碼
- A1表示包含安全信息的數(shù)據(jù)塊膨疏，A1=(user):(realm):(password)；
- QoP（保護質(zhì)量）钻弄，對不包含安全信息的數(shù)據(jù)設(shè)置保護方式佃却，可選項：auth、auth-int
- A2表示不包含安全信息的數(shù)據(jù)塊窘俺，根據(jù)qop值確定：
a) QoP=auth或undefined時双霍，A2=(request-method) : (uri-directive-value)
b) QoP=auth-int時，A2=(request-method) : (uri-directive-value) : H((entity-body))
（2）老摘要算法
兼容RFC2069,在沒有qop選項時使用批销。
算法：(以MD5算法為例)
KD(H(A1), (nonce) : H(A2))
= MD5(MD5(A1) : (nonce) : MD5(A2))
= MD5(MD5((user) : (realm) : (password)) : (nonce) : MD5((request-method) : (uri-directive-value)))
（3）新摘要算法
新摘要算法為推薦方式洒闸，包含了對隨機數(shù)計算和對稱認證的支持。只要qop為auth或auth-int均芽，就要使用這種方式丘逸。
算法：(以MD5算法，qop=auth-int為例)
KD(H(A1), (nonce) : (nc) : (cnonce) : (qop) : H(A2))
= MD5(MD5(A1) : (nonce) : (nc) : (cnonce) : (qop) : MD5(A2))
= MD5(MD5((user) : (realm) : (password)) : (nonce) : (nc) : (cnonce) : (qop) : MD5((request-method) : (uri-directive-value) : MD5((entity-body))))
例如掀宋，服務(wù)器response如下：
Authorization: Digest
username=”hu”
realm=”home”
nonce=”1” //服務(wù)器端的隨機數(shù)一起帶回
uri=”/login” //必須跟請求行一致
qop=”auth-int” //保護質(zhì)量參數(shù)
nc=0000001//nonce-count隨機數(shù)計數(shù)
cnonce=”3” //客戶端隨機數(shù)深纲，用于對稱校驗
response=”XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX”//最終摘要
response計算公式為 ：
MD5(MD5(hu:home:(password)):1:0000001:3:auth:MD5(login:MD5(body)))
http權(quán)威指南中似乎未對nc做說明，引用RFC2831中的一段說明：
The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay...
試著翻譯下：
nc-value指的是客戶端向服務(wù)器端發(fā)送帶有隨機數(shù)的請求次數(shù)（包含本次請求）的十六進制數(shù)(補充：八位十六進制數(shù))劲妙。例如湃鹊，當(dāng)?shù)谝淮伟l(fā)送帶有隨機數(shù)的請求時，客戶端發(fā)送”nc=00000001”镣奋。其目的是讓服務(wù)器能夠通過維護請求次數(shù)币呵，檢測到重復(fù)請求-如果相同的nc-value出現(xiàn)在兩次請求中，那么這兩次請求即為重復(fù)請求...
參考：https://www.ietf.org/rfc/rfc2... 搜索nonce-count
（4）機數(shù)選擇
RFC2617建議采用的隨機數(shù)公式：
Base64(time-stamp H(time-stamp : ETag : private-key))
以服務(wù)器端為例：time-stamp為服務(wù)器響應(yīng)請求的時間侨颈；ETag為請求實體有關(guān)的Http ETag首部（詳見瀏覽器緩存之協(xié)商緩存ETag）余赢；private-key是只有服務(wù)器知道的字符串芯义。保證不同請求時間，不同文件妻柒，產(chǎn)生不同隨機數(shù)扛拨。
（5）對稱認證
在客戶端接收到服務(wù)器端發(fā)回401響應(yīng)后，可以在發(fā)送授權(quán)請求的Authorization header中加上客戶端隨機數(shù)举塔，這就要求服務(wù)器端再收到第二次請求時绑警，將客戶端隨機數(shù)加入算法。
（6）請求摘要 & 響應(yīng)摘要
響應(yīng)摘要的計算方式與請求摘要類似央渣，但響應(yīng)中沒有方法计盒，報文實體數(shù)據(jù)也不同，這些信息影響A2的計算結(jié)果：
請求摘要(QoP=auth-int)：A2=(request-method) : (uri-directive-value) : H((request-entity-body))
響應(yīng)摘要(QoP=auth-int)：A2=:(uri-directive-value) : H((response-entity-body))
