Http Basic Auth 方式
當訪問一個Http Basic Auth 網站的時候需要提供用戶名，密碼，否則會返回401 (without authoration)。
Http Basic Authentication認證 有2種方式：
1、請求頭部Authorization 中添加 用戶名/密碼 的base64 編碼字符串。
2、url中拼用戶名和密碼。
市面上大部分瀏覽器支持url拼用戶名，密碼的方式訪問，
代碼不支持這種url 拼用戶名，密碼。
二、Http Basic Auth 原理
在HTTP協議進行通信的過程中，HTTP協議定義了基本認證過程以允許HTTP服務器對WEB瀏覽器進行用戶身份認證的方法，當一個客戶端向HTTP服務 器進行數據請求時，
如果客戶端未被認證，則HTTP服務器將通過基本認證過程對客戶端的用戶名及密碼進行驗證，以決定用戶是否合法。
客戶端在接收到HTTP服務器的身份認證要求後，會提示用戶輸入用戶名及密碼， 用戶輸入後，
客戶端將用戶名和密碼中間用“:”分隔合併，並將合併後的字符串用BASE64編碼，在每次請求數據 時，將密文附加於請求頭（Request Header）Authorization: Basic XXXXXXX中。
HTTP服務器在每次收到請求包後，根據協議取得客戶端附加的用戶信息（BASE64編碼的用戶名和密碼），解開請求包，對用戶名及密碼進行驗證，
如果用 戶名及密碼正確，則根據客戶端請求，返回客戶端所需要的數據;否則，返回錯誤代碼或重新要求客戶端提供用戶名及密碼。
三、Basic Auth 的優缺點
優點：提供簡單的用戶驗證功能，其認證過程簡單明瞭，適合於對安全性要求不高的系統或設備中。
缺點：輸入的用戶名，密碼 base64編碼後會出現在Authorization裏，很容易被解析出來。
DIGEST 認證
爲彌補 BASIC 認證存在的弱點，從 HTTP/1.1 起就有了 DIGEST 認證。 DIGEST 認證同樣使用質詢 / 響應的方式（challenge/response），但不會像 BASIC 認證那樣直接發送明文密碼。
所謂質詢響應方式是指，一開始一方會先發送認證要求給另一方，接着使用從另一方那接收到的質詢碼計算生成響應碼。最後將響應碼返回給對方進行認證的方式。
整個過程如下：
①瀏覽器發送http報文請求一個受保護的資源。
②服務端的web容器將http響應報文的響應碼設爲401，響應頭部比Basic模式複雜，WWW-Authenticate: Digest realm=”myTomcat”,qop=“auth”,nonce=“xxxxxxxxxxx”,opaque=“xxxxxxxx” 。其中qop的auth表示鑑別方式；nonce是隨機字符串；opaque服務端指定的值，客戶端需要原值返回。
③瀏覽器彈出對話框讓用戶輸入用戶名和密碼，瀏覽器對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合後進行MD5運算，把計算得到的摘要信息發送給服務端。請求頭部類似如下，Authorization: Digest username=“xxxxx”,realm=“myTomcat”,qop=“auth”,nonce=“xxxxx”,uri=“xxxx”,cnonce=“xxxxxx”,nc=00000001,response=“xxxxxxxxx”,opaque=“xxxxxxxxx” 。其中username是用戶名；cnonce是客戶端生成的隨機字符串；nc是運行認證的次數；response就是最終計算得到的摘要。
④服務端web容器獲取HTTP報文頭部相關認證信息，從中獲取到username，根據username獲取對應的密碼，同樣對用戶名、密碼、nonce值、HTTP請求方法、被請求資源URI等組合進行MD5運算，計算結果和response進行比較，如果匹配則認證成功並返回相關資源，否則再執行②，重新進行認證。
⑤以後每次訪問都要帶上認證頭部。
對比Basic認證
Digest思想，用了一種nonce隨機數字符串，雙方約好對哪些信息進行哈希運算即可完成雙方身份的驗證。Digest模式避免了密碼在網絡上明文傳輸，提高了安全性，但它仍然存在缺點，例如認證報文被攻擊者攔截到攻擊者可以獲取到資源，
DIGEST 認證提供了高於 BASIC 認證的安全等級，但是和 HTTPS 的客戶端認證相比仍舊很弱。DIGEST 認證提供防止密碼被竊聽的保護機制，但並不存在防止用戶僞裝的保護機制。DIGEST 認證和 BASIC 認證一樣，使用上不那麼便捷靈活，且仍達不到多數 Web 網站對高度安全等級的追求標準。因此它的適用範圍也有所受限。