目錄
一、basic基礎認證
二、digest摘要認證
三、ssl client認證
四、http 表單認證
http提供了一套標準的身份驗證框架：伺服器可以用來針對客戶端的請求傳送質詢(challenge)，客戶端根據質詢提供身份驗證憑證。質詢與應答的工作流程如下：伺服器端向客戶端返回401（unauthorized，未授權）狀態碼，並在www-authenticate頭中新增如何進行驗證的資訊，其中至少包含有一種質詢方式。然後客戶端可以在請求中新增authorization頭進行驗證，其value為身份驗證的憑證資訊。
在http標準驗證方案中，我們比較熟悉的是"basic"和"digest"，前者將使用者名稱密碼使用base64編碼後作為驗證憑證，後者是basic的公升級版，更加安全，因為basic是明文傳輸密碼資訊，而digest是加密後傳輸。
basic認證是一種較為簡單的http認證方式，客戶端通過明文（base64編碼格式）傳輸使用者名稱和密碼到服務端進行認證，通常需要配合https來保證資訊傳輸的安全。客戶端請求需要帶authorization請求頭，值為「basic ***」，***為「使用者名稱:密碼」進行base64編碼後生成的值。 若客戶端是瀏覽器，則瀏覽器會提供乙個輸入使用者名稱和密碼的對話方塊，使用者輸入使用者名稱和密碼後，瀏覽器會儲存使用者名稱和密碼，用於構造authorization值。當關閉瀏覽器後，使用者名稱和密碼將不再儲存。
憑證為「ywxhzgrpbjpvc**uc2vzywl1」，是通過將「使用者名稱:密碼」格式的字串經過的base64編碼得到的。而base64不屬於加密範疇，可以被逆向解碼，等同於明文，因此basic傳輸認證資訊是不安全的。
basic基礎認證圖示：
1.使用者名稱和密碼明文（base64）傳輸，需要配合https來保證資訊傳輸的安全。
2.即使密碼被強加密，第三方仍可通過加密後的使用者名稱和密碼進行重放攻擊。
3.沒有提供任何針對**和中間節點的防護措施。
4.假冒伺服器很容易騙過認證，誘導使用者輸入使用者名稱和密碼。
digest認證是為了修復digest認證步驟如下：基本認證
協議的嚴重缺陷而設計的，秉承「絕不通過明文在網路傳送密碼」的原則，通過「密碼摘要」進行認證，大大提高了安全性。
第一步：客戶端訪問http資源伺服器。由於需要digest認證，伺服器返回了兩個重要字段nonce（隨機數）和realm。
第二步：客戶端構造authorization請求頭，值包含username、realm、nouce、uri和response的字段資訊。其中，realm和nouce就是第一步返回的值。nouce只能被服務端使用一次。uri(digest-uri)即request-uri的值，但考慮到經****後request-uri的值可能被修改、因此實現會複製乙份副本儲存在uri內。response也可叫做request-digest，存放經過md5運算後的密碼字串，形成響應碼。
第三步：伺服器驗證包含authorization值的請求，若驗證通過則可訪問資源。
digest認證可以防止密碼洩露和請求重放，但沒辦法防假冒。所以安全級別較低。
digest和basic認證一樣，每次都會傳送authorization請求頭，也就相當於重新構造此值。所以兩者易用性都較差。
digest認證圖示：
參考部落格：
ssl認證安全級別較高，但需要承擔證書費用。ssl認證過程中涉及到一些重要的概念，數字證書機構的公鑰、證書的私鑰和公鑰、非對稱演算法（配合證書的私鑰和公鑰使用）、對稱金鑰、對稱演算法（配合對稱金鑰使用）。
大致的認證步驟如下：
第一步：客戶端請求服務資源，伺服器要求客戶端出示數字證書。
第二步：客戶端傳送數字證書
第三步：伺服器通過數字證書機構的公鑰驗證數字證書的合法性，驗證通過後取出證書的公鑰。
第四步：服務端隨機生成乙個隨機數即為對稱金鑰，並使用非對稱演算法和證書公鑰加密。這個加密後的字串，只有傳送的客戶端能解。
第五步：客服端使用非對稱解密演算法和證書私鑰獲取服務端傳送的對稱金鑰。後續客戶端和服務端的請求直接基於對稱演算法和對稱金鑰。由於只有客戶端和服務端有對稱金鑰，所以後續傳送的請求較安全。
ssl可以防洩漏、假冒、重放，所以在web系統中得到了廣泛的應用。
ssl客戶端認證在實際中用得不多，因為一來需要在客戶端中安裝證書（公升級麻煩）、二來需要承擔證書費用。
基於表單的認證方式並不存在於http規範。所以實現方式也呈現多樣化。表單認證一般都會配合cookie+sessiond的使用，現在絕大多數的web站點都是使用此認證方式。使用者在登入頁中填寫使用者名稱和密碼，服務端認證通過後會將sessionid返回給瀏覽器端，瀏覽器會儲存sessionid到瀏覽器的cookie中。因為http是無狀態的，所以瀏覽器使用cookie來儲存sessionid。下次客戶端傳送的請求中會包含sessionid值，服務端發現sessionid存在並認證過則會提供資源訪問。
HTTP協議基本認證
閱讀目錄 什麼是http基本認證 http基本認證的過程 http基本認證的優點 每次都要進行認證 http基本認證和https一起使用就很安全 http oauth認證 其他認證 客戶端的使用 桌面應用程式也通過http協議跟web伺服器互動，桌面應用程式一般不會使用cookie,而是把 使用者名...
HTTP協議 二 基本認證
閱讀目錄 什麼是http基本認證 http基本認證的過程 http基本認證的優點 每次都要進行認證 http基本認證和https一起使用就很安全 http oauth認證 其他認證 客戶端的使用 桌面應用程式也通過http協議跟web伺服器互動，桌面應用程式一般不會使用cookie,而是把 使用者名...
HTTP協議 二 基本認證
閱讀目錄 什麼是http基本認證 http基本認證的過程 http基本認證的優點 每次都要進行認證 http基本認證和https一起使用就很安全 http oauth認證 其他認證 客戶端的使用 桌面應用程式也通過http協議跟web伺服器互動，桌面應用程式一般不會使用cookie,而是把 使用者名...