引言
經(jīng)常在工作中使用到了各種認(rèn)證方式，但從未考慮過這些認(rèn)證方式所屬的知識范疇，同時(shí)也解釋不清楚它們。
曾用到的認(rèn)證方式（看看是否您也用過，但很難解釋清楚他們）：
- Basic認(rèn)證（訪問API時(shí)，瀏覽器會自動彈出一個(gè)對話框去輸入用戶名/密碼）
- 用戶名密碼認(rèn)證（進(jìn)入站點(diǎn)主頁前，需要在登陸頁面輸入用戶名和密碼，這種更專業(yè)的叫法為表單認(rèn)證）
- openID Connect認(rèn)證（用于第三方登陸認(rèn)證，比如微信提供給簡書的登錄認(rèn)證）
- Kerberos認(rèn)證（一種用于Hadoop集群的客戶端認(rèn)證）
經(jīng)過閱讀《圖解HTTP協(xié)議》這一書后，對HTTP認(rèn)證方式有了進(jìn)一步的了解。本文旨在簡單總結(jié)HTTP認(rèn)證方式。
HTTP中有如下常用認(rèn)證：
1、Basic認(rèn)證
2、Digest認(rèn)證
3、SSL Client認(rèn)證
4、表單認(rèn)證
HTTP Basic認(rèn)證
每次客戶端請求都需帶上Authorization請求頭， 值為"Basic xxx"。xxx為對用戶名和密碼進(jìn)行Base64編碼后的值。 若客戶端是瀏覽器，則瀏覽器會提供一個(gè)輸入用戶名和密碼的對話框，用戶輸入用戶名和密碼后，瀏覽器會保存用戶名和密碼，用于構(gòu)造Authorization值。當(dāng)關(guān)閉瀏覽器后，用戶名和密碼將不再保存。
用戶名/密碼經(jīng)過Base64加碼后，這個(gè)Base64碼值可以輕易被解碼并獲得用戶名/密碼，所以此認(rèn)證方式并不安全。為了傳輸安全，需要配合SSL使用。
HTTP另外 Digest認(rèn)證
Digest認(rèn)證步驟如下：
第一步：客戶端訪問Http資源服務(wù)器。由于需要Digest認(rèn)證，服務(wù)器返回了兩個(gè)重要字段nonce（隨機(jī)數(shù)）和realm。
第二步： 客戶端構(gòu)造Authorization請求頭，值包含username、realm、nouce、uri和response的字段信息。其中，realm和nouce就是第一步返回的值。nouce只能被服務(wù)端使用一次。uri(digest-uri)即Request-URI的值，但考慮到經(jīng)代理轉(zhuǎn)發(fā)后Request-URI的值可能被修改、因此實(shí)現(xiàn)會復(fù)制一份副本保存在uri內(nèi)。response也可叫做Request-digest，存放經(jīng)過MD5運(yùn)算后的密碼字符串，形成響應(yīng)碼。
第三步：服務(wù)器驗(yàn)證包含Authorization值的請求，若驗(yàn)證通過則可訪問資源。
Digest認(rèn)證可以防止密碼泄露和請求重放，但沒辦法防假冒。所以安全級別較低。
Digest和Basic認(rèn)證一樣，每次都會發(fā)送Authorization請求頭，也就相當(dāng)于重新構(gòu)造此值。所以兩者易用性都較差。
HTTP SSL Client認(rèn)證
SSL認(rèn)證安全級別較高，但需要承擔(dān)證書費(fèi)用。SSL認(rèn)證過程中涉及到一些重要的概念，數(shù)字證書機(jī)構(gòu)的公鑰、證書的私鑰和公鑰、非對稱算法（配合證書的私鑰和公鑰使用）、對稱密鑰、對稱算法（配合對稱密鑰使用）。
大致的認(rèn)證步驟如下：
第一步：客戶端請求服務(wù)資源，服務(wù)器要求客戶端出示數(shù)字證書。
第二步：客戶端發(fā)送數(shù)字證書
第三步：服務(wù)器通過數(shù)字證書機(jī)構(gòu)的公鑰驗(yàn)證數(shù)字證書的合法性，驗(yàn)證通過后取出證書的公鑰。
第四步：服務(wù)端隨機(jī)生成一個(gè)隨機(jī)數(shù)即為對稱密鑰，并使用非對稱算法和證書公鑰加密。這個(gè)加密后的字符串，只有發(fā)送的客戶端能解。
第五步：客服端使用非對稱解密算法和證書私鑰獲取服務(wù)端發(fā)送的對稱密鑰。后續(xù)客戶端和服務(wù)端的請求直接基于對稱算法和對稱密鑰。由于只有客戶端和服務(wù)端有對稱密鑰，所以后續(xù)發(fā)送的請求較安全。
SSL可以防泄漏、假冒、重放，所以在Web系統(tǒng)中得到了廣泛的應(yīng)用。
SSL客戶端認(rèn)證在實(shí)際中用得不多，因?yàn)橐粊硇枰诳蛻舳酥邪惭b證書（升級麻煩）、二來需要承擔(dān)證書費(fèi)用。
HTTP 表單認(rèn)證
基于表單的認(rèn)證方式并不存在于HTTP規(guī)范。所以實(shí)現(xiàn)方式也呈現(xiàn)多樣化。表單認(rèn)證一般都會配合cookie+sessiond的使用，現(xiàn)在絕大多數(shù)的Web站點(diǎn)都是使用此認(rèn)證方式。用戶在登錄頁中填寫用戶名和密碼，服務(wù)端認(rèn)證通過后會將sessionId返回給瀏覽器端，瀏覽器會保存sessionId到瀏覽器的Cookie中。因?yàn)镠ttp是無狀態(tài)的，所以瀏覽器使用Cookie來保存sessionId。下次客戶端發(fā)送的請求中會包含sessionId值，服務(wù)端發(fā)現(xiàn)sessionId存在并認(rèn)證過則會提供資源訪問。
