一些 Web 頁面只想讓特定的腾窝、擁有特定標(biāo)示的人瀏覽复唤，為了達到這個目標(biāo)叙量，必不可少的就是認證功能。生活中常見的認證方式包括：賬號密碼驗證予颤、動態(tài)令牌、指紋識別冬阳、人臉識別蛤虐、身份證驗證等等。那么肝陪，HTTP 常用的認證方式是什么呢驳庭？

HTTP 用戶身份認證

BASIC 認證

BASIC 認證（基本認證）是從 HTTP/1.0 就定義的認證方式。即便是現(xiàn)在仍有一部分的網(wǎng)站會使用這種認證方式见坑。是 Web 服務(wù)器與通信客戶端之間進行的認證方式嚷掠。

客戶端發(fā)出認證請求；
服務(wù)端接收到請求需要 BASIC 認證荞驴，會隨 401 狀態(tài)碼 Authorization Required不皆，返回帶 WWW-Authenticate 首部字段的響應(yīng)。該字段包含認證的方式（BASIC）及 Request-URI 安全域字符串（realm）熊楼；
客戶端接收到服務(wù)端的請求后霹娄，對用戶名和密碼進行 Base64 編碼處理，發(fā)送給服務(wù)器鲫骗；
服務(wù)端接收到客戶端的請求犬耻，對認證信息的正確性進行驗證，驗證通過后执泰，返回一條包含 Request-URI 資源的響應(yīng)枕磁。

需要注意的是，Base64 編碼并非加密處理术吝，因此计济，BASIC 認證實際是明文傳輸茸苇。

DIGEST 認證

客戶端發(fā)出認證請求；
服務(wù)器隨著狀態(tài)碼 401 Authorization Required沦寂，返回帶 WWW-Authenticate 首部字段的響應(yīng)学密。該字段內(nèi)包含認證所需的臨時質(zhì)詢碼（隨機數(shù)，nonce）传藏。
客戶端接收到包含 DIGEST 認證必須的首部 Authorization 信息腻暮。首部字段 Authorization 內(nèi)必須包含 username、realm毯侦、nonce哭靖、uri 和 response 的字段信息。其中叫惊，realm 和 nonce 就是之前從服務(wù)器接收到的響應(yīng)中的字段款青。
服務(wù)器確認認證信息的正確性，認證通過后則返回包含 Request-URI 資源的響應(yīng)霍狰。并且會在首部字段 Authentication-Info 中寫入一些認證成功的相關(guān)信息抡草。

DIGEST 認證提供了高于 BASIC 認證的安全等級，但是和 HTTPS 的客戶端認證相比仍舊很弱蔗坯。DIGEST 認證提供防止密碼被竊聽的保護機制康震，但并不存在防止用戶偽裝的保護機制。

SSL 客戶端認證

SSL客戶端認證是借由 HTTPS 的客戶端證書完成認證的方式宾濒。憑借客戶端證書認證腿短，服務(wù)器可確認訪問是否來自合法的客戶端。SSL 客戶端認證需要事先將客戶端證書分發(fā)給客戶端绘梦，且客戶端必須安裝此證書橘忱。

客戶端發(fā)出認證請求；
服務(wù)端接收到需要認證資源的請求卸奉，服務(wù)器會發(fā)送 Certificate Request 報文钝诚，要求客戶端提供客戶端證書。
用戶選擇將發(fā)送的客戶端證書后榄棵，客戶端將客戶端證書信息以 Client Certificate 報文方式發(fā)送給服務(wù)器凝颇。
服務(wù)器驗證客戶端證書，驗證通過后接受證書內(nèi)客戶端的公開密鑰疹鳄，開始 HTTPS 加密通信拧略。

SSL 客戶端認證采用雙因素認證，認證過程中不僅需要密碼這一個因素瘪弓，還需要申請認證者提供其他持有信息垫蛆，從而作為另一個因素，與其組合使用的認證方式。通過雙因素認證后月褥，就可以確認是用戶本人正在使用匹配正確的計算機訪問服務(wù)器弛随。

使用 SSL客戶端認證需要用到客戶端證書。而客戶端證書需要支付一定費用才能使用宁赤。每個認證機構(gòu)頒發(fā)客戶端證書的費用不盡相同，平攤到一張證書上栓票，一年費用約幾萬至十幾萬日元决左。服務(wù)器運營者也可以自己搭建認證機構(gòu)，但要維持安全運行就會產(chǎn)生相應(yīng)的費用走贪。

基于表單認證

基于表單的認證方法并不是在 HTTP 協(xié)議中定義的佛猛。客戶端會向服務(wù)器上的 Web 應(yīng)用程序發(fā)送登錄信息（Credential）坠狡，服務(wù)器根據(jù)登錄信息進行認證继找。

由于使用上的便利性及安全性問題，HTTP 協(xié)議標(biāo)準(zhǔn)提供的 BASIC 認證和 DIGEST 認證幾乎不怎么使用逃沿。另外婴渡，SSL客戶端認證雖然具有高度的安全等級，但因為導(dǎo)入及維持費用等問題凯亮，還尚未普及边臼。

不具備共同標(biāo)準(zhǔn)規(guī)范的表單認證，在每個 Web 網(wǎng)站上都會有各不相同的實現(xiàn)方式假消。如果是全面考慮過安全性能而實現(xiàn)的表單認證柠并，那么就能夠具備高度的安全等級。但在表單認證的實現(xiàn)中存在問題的 Web 網(wǎng)站也是屢見不鮮富拗。

基于表單認證一般會使用 Cookie 來管理 Session（會話）：

客戶端把用戶 ID 和密碼等登錄信息放入報文的實體部分臼予，通常是以 POST 方法把請求發(fā)送給服務(wù)器。而這時啃沪，會使用 HTTPS 通信來進行 HTML 表單畫面的顯示和用戶輸入數(shù)據(jù)的發(fā)送粘拾。
服務(wù)器返回用以識別用戶的 Session ID。通過驗證客戶端發(fā)送過來的登錄信息谅阿，進行身份認證半哟，然后把用戶的認證狀態(tài)與 Session ID 綁定后記錄在服務(wù)器端。
客戶端接收到從服務(wù)器端發(fā)來的 Session ID 后签餐，會將其作為 Cookie 保存在本地寓涨。下次向服務(wù)器發(fā)送請求時，瀏覽器會自動發(fā)送 Cookie氯檐，所以 Session ID 也隨之發(fā)送到服務(wù)器戒良。服務(wù)器端可通過驗證接收到的 Session ID 識別用戶和其認證狀態(tài)。

除了以上介紹的應(yīng)用實例冠摄，還有應(yīng)用其他不同方法的案例糯崎。另外几缭，不僅基于表單認證的登錄信息及認證過程都無標(biāo)準(zhǔn)化的方法，服務(wù)器端應(yīng)如何保存用戶提交的密碼等登錄信息等也沒有標(biāo)準(zhǔn)化沃呢。通常年栓，一種安全的保存方法是，先利用給密碼加鹽（salt）的方式增加額外信息薄霜，再使用散列（hash）函數(shù)計算出散列值后保存某抓。但是我們也經(jīng)常看到直接保存明文密碼的做法惰瓜，這樣的做法有密碼泄露的風(fēng)險否副。

salt 其實就是由服務(wù)器隨機生成的一個字符串，但是要保證長度足夠長崎坊，并且是真正隨機生成的备禀。然后把它和密碼字符串相連接（前后都可以）生成散列值。當(dāng)兩個用戶使用了同一個密碼時奈揍，由于隨機生成的 salt 值不同曲尸，對應(yīng)的散列值也將是不同的。這樣一來打月，很大程度上減少了密碼特征队腐，攻擊者也就很難利用自己手中的密碼特征庫進行破解。

最后

我的個人主頁里也同步進行了更新奏篙，歡迎來逛逛柴淘。