header 中的基本授權與正文中的用戶名和密碼

Question

我面臨兩種不同的情況。 第一種方法我可以在正文中發送用戶名和密碼作為 model。第二種方法是在 Header 中使用基本身份驗證。兩種方法都可以正常工作。 這兩種方法僅用於首次調用以進行身份驗證，api 返回 jwt 令牌。

第一種方法：

curl -X 'POST' \
  'https://localhost:7122/api/Authentication/token' \
  -H 'accept: text/plain' \
  -H 'Content-Type: application/json' \
  -d '{
  "userName": "test",
  "password": "test"
}'

第二種方法：

curl -L -X POST 'https://localhost:7122/api/Authentication/token' \
 -H 'Content-Type: application/x-www-form-urlencoded' \
 -H 'Authorization: Basic ZzI0N2NmbnlwYzV3cmszaHAwZnU2cTk3N2YzZzYxY2hnODV1NzJzZmJkb3c3LmFwcHMudml2YXBheW1lbnRzLmNvbTowYk9xOHRkMzhMQVF4b3ptaWVqUDYwUzdzQnJkVkQ=' \
 --data-urlencode 'grant_type=client_credentials'

它們是我應該在 jwt 令牌中使用什么的規則嗎？ 使用什么是好的做法？

Answer 1

為了確保每個人都在同一頁面上，讓我在這里概述一個典型的 JWT 身份驗證工作流程：

1. 用戶使用用戶名和密碼調用匿名 POST API（無需授權）。 API 然后返回 884645589888。這是您在第 3 行的Login名 API。

2. 所有其他 API 調用都需要授權，因此客戶端將其作為Bearer [JWT]發送。 服務器然后確定令牌是否有效，如果無效則返回 401。

據我了解這個問題，您問的是，對於 (1)，最好是使用基本身份驗證協議（base64 等）通過授權 header 發送 u/p，還是僅以明文形式將其發布在正文中登錄請求。

使用 auth header 我可以看到兩個缺點-

• 有時會記錄標頭，而很少記錄請求主體。 授予你，我認為系統記錄 auth 標頭是不尋常的（如果不是不可原諒的話），但這是可能的。 base64 編碼當然不提供安全性。
• 我過去在實際通過基本身份驗證標頭時遇到過困難。 我只會向您推薦這個探索一些可能的陷阱的線程。

除了可能的日志記錄問題外，我想不出使用一個與另一個的任何固有問題。 FWIW，我一直看到使用明文主體方法的 API，而我從未見過 API 讓您使用基本身份驗證登錄然后返回 JWT。

希望不言而喻，您必須確保您的 API 只能通過 HTTPS 訪問。否則無論您將密碼放在哪里，您都會被盜用。

也就是說，如果您是從頭開始設計這個並且可以訪問系統的兩端並且它們將始終同步，我會考慮發送一個散列密碼，無論您使用 auth header 還是 POST 正文。 只要您的客戶端和服務器就散列方法和迭代計數達成一致，就可以顯着降低數據可能泄漏或記錄在某處的影響。 不過，這需要一些本土安全工作。

至於你的另一個問題，

它們是我應該在 jwt 令牌中使用什么的規則嗎？ 使用什么是好的做法？

規則？ 不，慣例，當然。 最終，它是應用程序需要能夠信任用戶並授予他們訪問權限的任何信息。 這些將以“索賠”的形式出現。 有很多關於這方面的文獻，但權威機構是RFC 。