HTTP協議規范中有兩種認證方式，一種是Basic認證，另外一種是Digest認證，這兩種方式都屬于無狀態認證方式，所謂無狀態即服務端都不會在會話中記錄相關信息，客戶端每次訪問都需要將用戶名和密碼放置報文一同發送給服務端，但這并不表示你在瀏覽器中每次訪問都要自己輸入用戶名和密碼，可能是你第一次輸入賬號后瀏覽器就保留在內存中供后面的交互使用。先看下HTTP協議的Basic認證模式。

既然是HTTP協議規范，那其實就是約束瀏覽器廠商與web容器廠商實現各自軟件時的行為約束，例如典型的一個認證交互過程是：瀏覽器向web容器發送http請求報文，web容器接收到http請求報文后解析需要訪問的資源，如果該資源剛好是受保護資源，web容器則向瀏覽器發送認證http響應報文，瀏覽器接收到報文后彈出窗口讓用戶輸入賬號及密碼，接著再次發送包含了賬號信息的http請求報文，web容器對賬號信息進行鑒權，通過驗證則返回對應資源，否則重新認證。

Basic Access Authentication scheme是在HTTP1.0提出的認證方法，它是一種基于challenge/response的認證模式，針對特定的realm需要提供用戶名和密碼認證后才可訪問，其中密碼使用明文傳輸。Basic模式認證過程如下：

①瀏覽器發送http報文請求一個受保護的資源。

②服務端的web容器將http響應報文的響應碼設為401，響應頭部加入WWW-Authenticate: Basic?realm=”myTomcat”。

③瀏覽器彈出對話框讓用戶輸入用戶名和密碼，并用Base64進行編碼，實際是用戶名+冒號+密碼進行Base64編碼，即Base64(username:password)，這次瀏覽器就會在HTTP報文頭部加入Authorization: Basic bXl0b21jYXQ=。

④服務端web容器獲取HTTP報文頭部相關認證信息，匹配此用戶名與密碼是否正確，是否有相應資源的權限，如果認證成功則返回相關資源，否則再執行②，重新進行認證。

⑤以后每次訪問都要帶上認證頭部。

服務端返回的認證報文中包含了realm=”myTomcat”，realm的值用于定義保護的區域，在服務端可以通過realm將不同的資源分成不同的域，域的名稱即為realm的值，每個域可能會有自己的權限鑒別方案。

Basic認證模式有兩個明顯的缺點：①無狀態導致每次通信都要帶上認證信息，即使是已經認證過的資源；②傳輸安全性不足，認證信息用Base64編碼，基本就是明文傳輸，很容易對報文截取并盜用認證信息。

?

轉載于:https://www.cnblogs.com/ostin/p/9327926.html

總結

以上是生活随笔為你收集整理的认证模式之Basic模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。