每個整合了第三方 API 的開發人員都遇到了同樣的障礙:文件說 "使用基本驗證進行身份驗證,"您將金鑰和秘密貼到請求中,伺服器以平面回應 401 Unauthorized 沒有任何關於原因的提示。憑證十分之九的編碼略有錯誤,錯誤中沒有任何內容可以告訴你這一點。我已經在 WordPress 外掛程式和 Laravel 後端建立並消耗了足夠多的 API,以至於浪費了令人尷尬的時間,所以我放了一個 基本驗證產生器 在 工具。dev 每次都能正確建立標頭,並在需要檢查時解碼回標頭。這是它及其背後方案的指南。
TL;DR: HTTP 基本驗證將使用者名稱和密碼傳送為
base64(username:password)在Authorization標題。工具 基本驗證產生器 將使用者名稱和密碼轉換為精確的標頭、準備運行的捲曲命令、獲取片段和 URL 使用者資訊表單,然後解碼現有的令牌。它透過 UTF-8 進行編碼,以便非 ASCII 憑證能夠生存,當使用者名稱包含冒號時發出警告,並且完全在客戶端運行。
什麼是 HTTP 基本驗證?
HTTP 基本驗證是 Web 定義的最簡單的憑證方案。它是在中指定的 RFC 7617,它位於通用 HTTP 身份驗證框架之上 RFC 7235。 這個想法很小:為了證明你是誰,你發送了一個 Authorization 其值為單字的標題 Basic,一個空格,然後由單一冒號連接的使用者名稱和密碼的 base64 編碼。
具體來說,如果您的用戶名是 admin 你的密碼是 secret,客戶端形成字串 admin:secret,將其編碼為 UTF-8 字節,以 64 為基數對要取得的字節進行編碼 YWRtaW46c2VjcmV0,並發送:
Authorization: Basic YWRtaW46c2VjcmV0
這就是整個方案。沒有握手,沒有隨機數,沒有雜湊。它的簡單性正是它得以倖存的原因:在兩端實現是微不足道的,對於內部工具、私人註冊表、網路掛鉤和無數 API 來說,它仍然是預設值。問題是,編碼是完全可逆的,這影響瞭如何使用它的一切。
base64 編碼與加密相同嗎?
不,這是關於 Basic auth 最重要的事情。 Base64,定義於 RFC 4648,是一種傳輸編碼。其目的是使用一組安全的 64 個可列印字元來表示二進位或文字數據,以便它能夠通過期望文字的系統發送。它不是密碼,不使用金鑰,反轉只需一步。任何能看到的人 YWRtaW46c2VjcmV0 可以解碼回 admin:secret 立即,這就是這個工具's解碼模式的作用。
結果是基本身份驗證本身提供的機密性為零。憑證實際上是在清晰的情況下發送的,只是進行了薄薄的偽裝。這就是為什麼 Basic auth 的一個不可協商的規則是它只能透過 HTTPS 傳輸。 TLS 對整個請求進行加密,包括 Authorization 標頭,因此 base64 憑證在傳輸過程中受到保護。透過普通 HTTP 發送基本驗證,並且您已將密碼發佈到網路路徑上的任何人。
我之所以努力這一點,是因為 base64 欺騙了人們,讓他們認為憑證是以某種有意義的方式打亂的。不是。像對待原始密碼一樣小心對待 base64 代幣,因為它們是微不足道的相互轉換。這 資料隱私線上工具 指南介紹了為什麼該工具在瀏覽器中而不是在伺服器上進行編碼,這對於即時憑證來說是重點。
基本 auth 標頭是如何逐步建構的?
構造有四個小步驟,如果其中任何一個步驟稍微錯誤,就會產生一個默默失敗的憑證:
- 用冒號連接。 形成字串
username:password. 冒號是分隔符號。 - 編碼為 UTF-8。 使用 UTF-8 將該字串轉換為位元組。這對於任何非 ASCII 字元都很重要。
- Base64 對位元組進行編碼。 應用標準 base64 來產生令牌。
- 前綴與
Basic. 最終標頭值為Basic接下來是令牌。
的 產生器 完成所有四個操作並將完成的標頭交給您。它還產生您實際貼上到終端或程式碼庫中的表單:使用 curl 指令 -u 標誌,帶有顯式 curl 指令 -H 'Authorization: Basic ...' 標頭、取得片段、裸令牌本身以及 URL 使用者資訊表單 https://user:pass@host. 不同的任務需要不同的形式,而手動重新輸入 base64 正是錯誤不斷出現的地方。
為什麼使用者名稱比密碼更重要?
該計劃中存在一種不對稱性,它不斷地使人們絆倒,而且它直接來自第一步。憑證是分開的 第一的 冒號。這意味著使用者名稱不能包含冒號,因為伺服器會將使用者名稱中的第一個冒號讀取為邊界,並將其餘部分交給密碼欄位。相比之下,密碼可以包含任意數量的冒號,因為第一個冒號之後的所有內容都是密碼。
RFC 7617 直接說明了這一點:使用者 ID 不得包含冒號。這很容易在不被注意到的情況下被違反,特別是當使用者名稱本身是類似於 API 金鑰或恰好包含冒號的信號形狀的標識符時。生成器會準確監視此訊息,並在使用者名稱包含冒號時向您發出警告,因為產生的憑證將在錯誤位置進行分割時解碼,並產生 401,不會給您任何有關原因的線索。
這是表格中的規則,因為它值得明確。
| 田野 | 可能含有結腸? | 原因 |
|---|---|---|
| 用戶名 | 不 | 第一個冒號是分隔符號 |
| 密碼 | 是的 | 第一個冒號之後的一切都是密碼 |
我在野外調試了這個確切的故障,其中一項服務發布了 API "用戶名和報價;偶爾包含冒號,整合對大多數客戶有效,但對少數客戶卻神秘失敗。該工具和#39;的警告本來可以挽救那天下午。
為什麼 UTF-8 編碼很重要?
對於全 ASCII 使用者名稱和密碼,編碼步驟是不可見的;每個字元都是一個字節,base64 做它的事情。當憑證包含重音字母、非拉丁腳本或表情符號時,位元組編碼就變得具有決定性。 RFC 7617 精確推薦 UTF-8,以便客戶端和伺服器就這些字元的位元組達成一致。
假設一個字元是一個位元組的樸素編碼器,或依賴具有遺留行為的瀏覽器 API,將會損壞 café 或者 пароль 輸入錯誤的字節,它產生的 base64 令牌將無法與從相同憑證計算的相容伺服器相符。結果是另一個靜音 401。此產生器手動對 UTF-8 上的憑證進行編碼,因此密碼類似 café:naïve 準確地產生 RFC 7617 用戶端將發送的字節,解碼方忠實地反轉它。如果您曾經擁有適用於一名隊友而不是另一名隊友的憑證,則編碼不一致的非 ASCII 字元是主要嫌疑犯。
如何解碼基本驗證令牌?
由於編碼是可逆的,因此檢查憑證就像產生憑證一樣簡單。之後就去做吧 Basic ,base64-解碼它,將結果讀作utf-8,並在第一個冒號上分割。這 產生器's 解碼模式可以做到這一點:貼上完整 Authorization: Basic ... 線,裸露 Basic ... 值,或只是令牌,它會向您顯示它攜帶的使用者名稱和密碼。
這確實有用,而不僅僅是好奇心。當您收到工作憑證並被要求在新環境中複製它時,解碼會準確地告訴您它編碼的使用者名稱和密碼,以便您可以正確設定它們。當整合失敗時,解碼您實際發送的令牌並將其與您的意圖進行比較通常是發現錯誤位置的雜散空間、錯誤欄位或冒號的最快方法。這生動地提醒了上面的保密點:如果您可以輕鬆解碼它,那麼任何透過普通 HTTP 攔截它的人也可以。
產生器與其他工具配合的地方
基本授權是網站上共享相同客戶端免上傳模型的多個憑證和請求工具之一。當您檢查的令牌是承載令牌而不是基本授權時, JWT解碼器 從 JSON Web 令牌中讀取聲明。當您需要雜湊而不是編碼時,對於校驗和或密碼摘要, 哈希生成器 計算它。當您只想對任意 base64 而不是特定的憑證進行編碼或解碼時, base64 轉換器 處理一般情況。當您調試請求本身並想知道客戶端發送了什麼時, 用戶代理解析器 讀取 User-Agent 標頭。
有關這些請求和回應實用程式如何協同工作的更廣闊的地圖, web 開發人員工具包 綜述將瀏覽真實的調試會話,並且 開發人員生產力工具 指南涵蓋了組裝一組個人文件。基本授權很少單獨出現;它通常是您嘗試製作的請求中的一行。
一個可行的例子:連接 API 整合
讓我將其紮根於我最常執行的任務中。您正在整合第三方服務,其文件要求使用 API 金鑰作為使用者名稱和空密碼或金鑰和秘密對與基本驗證進行身份驗證。這些文件為您提供憑證,但不提供標頭,並且第一個請求失敗。
可靠的路徑是明確建立標頭並在編寫一行應用程式程式碼之前用 curl 進行測試。將密鑰和秘密貼到其中 產生器,複製 curl -H 形成,並根據已知端點運行它。如果 curl 成功而您的程式碼失敗,問題出在您的程式碼中'請求構造,而不是憑證,並且您剛剛將搜尋空間切成兩半。如果 curl 也失敗,則憑證本身是錯誤的,並且解碼令牌可以準確確認哪個欄位已關閉。
在 WordPress 外掛程式中,我經常需要從 PHP 呼叫外部 API,正確的標頭值就是我輸入的 wp_remote_get 透過 Authorization 標題參數。在 Laravel 中,它進入了 withHeaders 呼叫 HTTP 用戶端,否則我使用框架's withBasicAuth helper,它為我建立了相同的標頭。無論哪種方式,擁有生成器中已知的良好標頭值意味著我正在根據我已經證明有效的憑證調試我的請求代碼,而不是同時調試兩者。空密碼情況是生成器獲得保留的地方,因為很容易忘記這一點 key: 尾隨冒號是一種不同的且通常是正確的憑證 key 獨自的。
最後一個規則是安全規則。不要將產生的標頭貼上到共享文件、票證或聊天中,並且不要透過 HTTPS 以外的任何內容發送基本授權。令牌是密碼。因為該工具在您的瀏覽器中編碼並且從不上傳任何內容,因此產生憑證是安全的;它隨後去的地方就在你身上。
我什麼時候應該使用基本授權,什麼時候不應該使用?
基本授權並不是每項工作的正確工具,知道它適合哪裡可以讓您擺脫麻煩。它的優點是簡單:對於伺服器到伺服器的呼叫、內部工具、私人套件註冊表、CI 作業和網路掛鉤,兩端已經相互信任,一切都透過 HTTPS 運行,很難擊敗。沒有什麼可以協商的,沒有可以刷新的令牌,每個 HTTP 用戶端和庫都開箱即用地支援它。當您控制雙方並且連接加密時,Basic auth 是一個完全合理的選擇,已經運行了三十年。
當你走出那個盒子時,它的弱點就會顯現出來。因為憑證是根據每個請求發送的,單一洩漏的日誌行或記錄標頭的代理程式會永久暴露它,而旋轉它意味著立即將其更改為所有地方。它沒有範圍的概念,因此基本憑證是全有或全無的:它不能授予唯讀存取權限或在一小時後過期。它在每次通話時都會在電線上放置一個真實的、長壽命的密碼,而基於令牌的方案則允許您分發一個短暫的、範圍狹窄的憑證。
對於面向使用者的身份驗證,或任何您需要範圍、到期或撤銷的地方,承載令牌是更好的模型,並且 JWT解碼器 是檢查這些的配套工具。一個有用的經驗法則:達到機器對機器呼叫的基本授權,您可以完全控制,並在涉及第三方、瀏覽器會話或權限邊界時達到令牌。下表總結了交易。
| 使用基本授權 | 更喜歡代幣 |
|---|---|
| 伺服器到伺服器的 API 呼叫您的控制 | 面向使用者的會話 |
| 內部工具和私人註冊表 | 範圍界定或唯讀存取 |
| 透過 HTTPS 進行 CI 作業和網路掛鉤 | 必須過期的憑證 |
常見問題
什麼是 HTTP 基本驗證? HTTP 基本驗證是一種方案,客戶端在授權標頭中隨每個請求發送使用者名稱和密碼。該值是"Basic"一詞,後面跟著"username:password"的 base64 編碼。它在 RFC 7617 中定義,是伺服器檢查憑證的最簡單方法。
基本 auth 標頭是如何建構的? 使用單一冒號加入使用者名稱和密碼以形成使用者名稱:密碼,將該字串編碼為 UTF-8 位元組,以 64 為基數對位元組進行編碼,並在結果前面加上 Basic。最後的標題是授權:基本,後面跟著該令牌。
基本身份驗證安全嗎? 僅透過 HTTPS。 Base64 是編碼,而不是加密,因此任何能夠讀取標頭的人都可以立即解碼密碼。基本 auth 本身不提供機密性,必須始終透過 TLS 連線發送才能安全。
使用者名稱可以包含冒號嗎? 否。第一個冒號將使用者名稱與密碼分開,因此使用者名稱中的冒號會被誤讀為邊界,並將憑證分割到錯誤的位置。密碼可能包含任意數量的冒號。如果使用者名稱有冒號,生成器會警告您。
如何解碼基本驗證令牌? 將 base64 部分放在 Basic 之後,base64 解碼它,並將其讀取為 UTF-8 文字。結果是使用者名稱:密碼,在第一個冒號上分割。將任何 Basic auth 標頭貼到工具中's 解碼模式即可立即執行此操作。
捲曲等價物是什麼? curl -u 使用者名稱:密碼 https://example.com 做同樣的事情,因為 curl 從 -u 值為您建立授權:基本標頭。該工具顯示該表單和顯式 -H 標頭表單,以便您可以複製適合的表單。
該工具可以將我的憑證發送到任何地方嗎? 不。編碼和解碼完全在您的瀏覽器中使用 JavaScript 運行。您的使用者名稱和密碼永遠不會上傳到任何伺服器,因此可以安全地與真實的即時憑證一起使用。
為什麼要對憑證使用 UTF-8 編碼? RFC 7617 建議使用 UTF-8,以便非 ASCII 使用者名稱和密碼在客戶端和伺服器之間一致編碼。假設 ASCII 會損壞重音字母或非拉丁腳本的編碼器,產生伺服器無法匹配的令牌。
