【讀】這一次,讓咱們再深刻一點 - HTTP的基本認證機制

這是網絡系列的第九篇文章,接下來會有更多精彩內容.敬請期待! 讓咱們一塊兒乘風破浪!

前言

哈哈, 很久沒和你們一塊兒學習了. 春節有沒有很嗨皮啊? 反正我是懶着過去的....今天再和你們一塊兒進步一點點.

網絡的資源如此之多, 但有些資源爲了安全, 不是全部人均可以看到的. 此時, 服務器須要客戶端證實本身 的身份, 該篇一塊兒來了解下HTTP的基本認證機制.

HTTP的質詢/響應認證框架

HTTP提供了一套原生的質詢/響應(challenge/response)框架. 其認證模型以下:

• 在客戶端發起HTTP請求時, 服務器並無直接完成客戶端的需求, 而是以"認證質詢"的方式響應, 要求客戶端提供身份信息.
• 客戶端再次請求時, 就要附帶證實其身份的信息(用戶名密碼或證書等), 向服務器說明本身的真實性.

須要瞭解的幾個問題

認證協議與首部

HTTP的質詢/響應框架支持兩種官方的認證協議: 基本認證和摘要認證(摘要認證會在後續文章中一塊兒學習). 兩種協議對應的HTTP首部及內容也有所區別.先來看看基本認證協議使用的首部信息.

認證步驟	首部	描述	方法/狀態
請求		在不知道須要認證時沒有具體首部	GET
質詢	WWW-Authenticate	服務器返回狀態碼401,拒絕請求; 要求客戶端提供用戶名和密碼. 服務器可能分爲不一樣的區域,每一個區域都須要不一樣的認證, 這些信息都會在WWW-Authenticate響應頭中描述; 該首部也會包含對應的認證算法.	401 Unauthorized
受權	Authorization	客戶端再次發出請求, 附加Authorization首部, 說明用戶名和密碼已經認證算法.	GET
成功	Authentication-Info	若認證經過, 服務器返回對應資源. 能夠在該響應頭中返回附件信息.	200 OK

參考下面的實例:

安全域

在上述實例中, 質詢的響應包含了WWW-Authenticate: Basic realm="Family"的信息; 服務器可能會把多個文檔劃分在不一樣的域中, realm是服務器對各個域的標識. 不一樣的域可能須要不一樣的認證.

Base-64編碼

在上述實例的C請求中, 用戶名和密碼通過Base-64編碼以後經過Authorization首部傳到服務器. 這裏並非明文傳輸.更多關於Base-64的說明看這裏.固然,這一步的轉換並不能保證用戶名和密碼的安全.

代理認證

代理做爲web結構中的實體, 也能夠爲用戶提供認證的功能.示意圖以下:

使用代理進行認證, 是一種快捷管理的方式. 能夠看到, 認證過程和web服務器的認證過程相同.但相關頭信息和狀態碼不一樣:

web服務器首部	代理認證首部
Unauthorized status code 401	Unauthorized status code 407
WWW-Authenticate	Proxy-Authenticate
Authorization	Proxy-Authorization
Authentication-Info	Proxy-Authentication-Info

基本認證存在的問題

在瞭解了基本認證的過程後, 能夠了解到它存在的一些問題:

• 用戶名和密碼經過網絡經Base-64編碼後傳輸, 會致使第三方截獲並解碼後獲取用戶的隱私信息.

• 即便第三方沒法直接獲取用戶名密碼, 也能夠經過 將截獲的數據重放給服務器以獲取服務器的訪問權限.

• 用戶面對大量的用戶名和密碼時, 有可能使用相同的密碼, 這將帶來"撞庫"的危險.

• 總之, 基本認證存在很大的風險.

結語

該篇和你們一塊兒瞭解了HTTP的基本認證框架. 除了基本的認證, HTTP還支持摘要認證, 下篇咱們繼續學習.到時候見!

注

• 部分圖片來源於網絡，若有侵權，請告知。
• 若有錯誤，還請指出。共勉！
• 您的喜歡是最大的讚揚。