HTTP 身份驗證

RFC 7235 定義了 HTTP 身份驗證框架，伺服器可以使用該框架來 質詢 客戶端請求，客戶端可以使用該框架來提供身份驗證資訊。

質詢和響應流程如下所示

1. 伺服器使用 401（未授權）響應狀態回覆客戶端，並提供有關如何授權的資訊，方法是使用包含至少一個質詢的 WWW-Authenticate 響應頭。
2. 想要向伺服器進行身份驗證的客戶端可以透過在請求頭中包含 Authorization 和憑據來實現。
3. 通常，客戶端會向用戶顯示密碼提示，然後發出包含正確 Authorization 頭的請求。

上述通用訊息流對於大多數（如果不是全部）身份驗證方案 都是相同的。頭資訊中的實際資訊及其編碼方式確實會發生變化！

相同的質詢和響應機制可用於代理身份驗證。由於資源身份驗證和代理身份驗證可以共存，因此需要一組不同的頭和狀態程式碼。對於代理，質詢狀態程式碼為 407（需要代理身份驗證），Proxy-Authenticate 響應頭包含至少一個適用於代理的質詢，並且 Proxy-Authorization 請求頭用於向代理伺服器提供憑據。

如果（代理）伺服器收到無效的憑據，則應使用 401 Unauthorized 或 407 Proxy Authentication Required 進行響應，使用者可以傳送新請求或替換 Authorization 頭欄位。

如果（代理）伺服器收到有效但不足以訪問給定資源的憑據，則伺服器應使用 403 Forbidden 狀態程式碼進行響應。與 401 Unauthorized 或 407 Proxy Authentication Required 不同，此使用者無法進行身份驗證，瀏覽器不會建議進行新的嘗試。

在所有情況下，伺服器可能更傾向於返回 404 Not Found 狀態程式碼，以向許可權不足或未正確進行身份驗證的使用者隱藏頁面的存在。

一個潛在的安全漏洞（此後已在瀏覽器中修復）是跨站點影像的身份驗證。從 Firefox 59 開始，從與當前文件不同的源載入的影像資源將不再能夠觸發 HTTP 身份驗證對話方塊（Firefox bug 1423146），防止攻擊者能夠將任意影像嵌入到第三方頁面中時竊取使用者憑據。

瀏覽器使用 utf-8 編碼使用者名稱和密碼。

Firefox 曾經使用 ISO-8859-1，但為了與其他瀏覽器保持一致並避免 Firefox bug 1419658 中描述的潛在問題，已更改為 utf-8。

WWW-Authenticate 和 Proxy-Authenticate 響應頭定義了應用於訪問資源的身份驗證方法。它們必須指定使用哪種身份驗證方案，以便希望進行授權的客戶端知道如何提供憑據。

這些頭的語法如下所示

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

此處，<type> 是身份驗證方案（“Basic”是最常見的方案，並在 下面介紹）。realm 用於描述受保護的區域或指示保護範圍。這可能是一條訊息，例如“訪問登臺站點”或類似訊息，以便使用者知道他們嘗試訪問哪個空間。

Authorization 和 Proxy-Authorization 請求頭包含用於對使用者代理與（代理）伺服器進行身份驗證的憑據。此處，再次需要 <type>，後跟憑據，這些憑據可以根據使用的身份驗證方案進行編碼或加密。

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

通用 HTTP 身份驗證框架是許多身份驗證方案的基礎。

IANA 維護了一個 身份驗證方案列表，但主機服務（如 Amazon AWS）也提供了其他方案。

一些常見身份驗證方案包括

Basic

請參閱 RFC 7617，base64 編碼的憑據。更多資訊請見下文。

Bearer

請參閱 RFC 6750，用於訪問 OAuth 2.0 保護的資源的承載令牌

Digest

請參閱 RFC 7616。Firefox 93 及更高版本支援 SHA-256 演算法。以前版本僅支援 MD5 雜湊（不推薦）。

HOBA

請參閱 RFC 7486，第 3 節，HTTP Origin-Bound Authentication，基於數字簽名的身份驗證

Mutual

請參閱 RFC 8120

Negotiate / NTLM

請參閱 RFC4599

VAPID

請參閱 RFC 8292

SCRAM

請參閱 RFC 7804

AWS4-HMAC-SHA256

請參閱 AWS 文件。此方案用於 AWS3 伺服器身份驗證。

方案在安全性強度和客戶端或伺服器軟體中的可用性方面可能有所不同。

“Basic”身份驗證方案的安全性非常差，但支援廣泛且易於設定。下面將詳細介紹它。

“Basic”HTTP 身份驗證方案在 RFC 7617 中定義，該方案將憑據作為使用者 ID/密碼對傳輸，並使用 base64 進行編碼。

由於使用者 ID 和密碼作為明文透過網路傳遞（它是 base64 編碼的，但 base64 是一種可逆編碼），因此基本身份驗證方案不安全。應將 HTTPS/TLS 與基本身份驗證一起使用。如果沒有這些額外的安全增強功能，則不應使用基本身份驗證來保護敏感或有價值的資訊。

要對 Apache 伺服器上的目錄進行密碼保護，您將需要一個 .htaccess 檔案和一個 .htpasswd 檔案。

.htaccess 檔案通常如下所示

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

.htaccess 檔案引用了一個 .htpasswd 檔案，其中每一行都包含一個使用者名稱和一個密碼，用冒號 (:) 分隔。您無法看到實際的密碼，因為它們已 雜湊（在這種情況下，使用基於 MD5 的雜湊）。請注意，如果您願意，可以將 .htpasswd 檔案命名為其他名稱，但請記住，此檔案不應供任何人訪問。（Apache 通常配置為阻止訪問 .ht* 檔案）。

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

對於 Nginx，您需要指定要保護的位置以及提供密碼保護區域名稱的 auth_basic 指令。然後，auth_basic_user_file 指令指向一個 .htpasswd 檔案，其中包含加密的使用者憑據，就像上面的 Apache 示例一樣。

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

許多客戶端還允許您透過使用包含使用者名稱和密碼的編碼 URL 來避免登入提示，如下所示

https://username:password@www.example.com/

不建議使用這些 URL。出於安全原因，Chrome 中的 URL 中的 username:password@ 部分已 從子資源 URL 中刪除。在 Firefox 中，它會檢查站點是否確實需要身份驗證，如果不需要，Firefox 會向用戶發出提示“您即將使用使用者名稱 username 登入到站點 www.example.com，但該網站不需要身份驗證。這可能是欺騙您的嘗試。”如果站點確實需要身份驗證，則 Firefox 仍會在將憑據傳送到站點之前提示使用者確認“您即將使用使用者名稱 username 登入到站點 www.example.com。”請注意，Firefox 在顯示提示之前會先在兩種情況下都不帶憑據地傳送請求，以確定站點是否需要身份驗證。

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407