第一次我必須在 Laravel API 上調試損壞的 auth 流程時,我浪費了一個下午的時間,因為我無法產生我信任的令牌。中間件不斷傳回 401,我無法判斷該錯誤是在我的驗證碼中還是在我提供給它的令牌中。我需要一個已知的、好的 JWT 和特定的 sub,一個特定的到期日,以及我控制的秘密,這樣我就可以隔離問題的一側。從堆疊溢位答案複製隨機令牌的作用與幫助相反,因為它是用我沒有的秘密簽署的。
這就是 JWT 產生器所填補的空白。這不是生產簽名服務。當您正在建立或測試消耗 JSON Web 代幣的東西時,它是一個工作台工具,您需要一個有效的按需代幣,其中包含您選擇的確切聲明和確切的秘密。本指南介紹了該工具的工作原理、JWT 的組裝和簽名方式,以及手動產生代幣可以即時節省您的實際情況。
TL;DR: JWT 產生器將 JSON 有效負載加上秘密轉換為簽名令牌。貼上您的聲明,選擇 HS256、HS384 或 HS512,輸入秘密,然後複製令牌。這 JWT 產生器 使用瀏覽器 Web Crypto API 進行簽名,因此有效負載和秘密永遠不會離開您的電腦。使用它來建立具有已知功能的測試令牌
sub、設定到期或故意到期exp練習您的 API's 錯誤路徑。要讀取令牌回溯,請將其與配對 中國航空解碼器.
什麼是 JWT 以及產生器產生什麼?
JSON Web 令牌是一種緊湊、URL 安全的方式來表示一組聲明。該結構由 RFC 7519 定義,簽名形式幾乎每個人都是用 " 表達的; JWT,"是 RFC 7515 定義的 JSON Web 簽名。簽名令牌由三個部分組成,由點連接: header.payload.signature.
標頭是一個小型 JSON 對象,命名簽名演算法和令牌類型,類似 { "alg": "HS256", "typ": "JWT" }. 有效負載是聲明的 JSON 物件:令牌是關於誰的、何時到期以及您的應用程式新增的任何自訂欄位。標頭和有效負載均採用 Base64url 編碼,這是普通的 base64,有兩個字元替換,沒有填充,完全符合 RFC 7515 的規定。簽名是在前兩部分計算的鍵控雜湊。
生成器組裝所有三個。您提供有效負載和秘密,它會建立標頭,對兩個段進行編碼,計算簽名並連接它們。輸出是一個字串,您可以直接放入一個字串中 Authorization: Bearer 標頭、測試夾具或 curl 命令。
有一件事值得坦白:簽署的 JWT 是經過編碼的,而不是加密的。任何持有代幣的人都可以 Base64url 解碼有效負載並讀取其中的每個聲明。簽名不會隱藏內容。它只能證明內容沒有被沒有金鑰的人更改。切勿在 JWT 有效負載內放置密碼、API 金鑰或任何其他您不會向使用者顯示的內容。
簽名如何進行?
對於 HMAC 系列來說,該工具使用的是簽名 HMAC(secret, header + "." + payload). HMAC 是 RFC 2104 定義的鍵控雜湊結構,JWA 規範 RFC 7518 將三個 JWT 演算法名稱對應到其上:HS256 使用 HMAC 和 SHA-256,HS384 使用 SHA-384,HS512 使用 SHA-512。
重要的屬性是對稱性。相同的秘密會建立並驗證簽名。當您的伺服器收到令牌時,它會重新計算 HMAC(secret, header + "." + payload) 接收到的前兩個段並檢查結果是否等於簽名段。如果有效負載的單一位元組發生更改,則重新計算的雜湊值將不匹配且驗證失敗。這就是整個完整性保證。
因為它是對稱的,所以秘密就是整個遊戲。任何擁有秘密的人都可以為您的系統鑄造有效的代幣,這就是為什麼生成器透過 Web Crypto API 在您的瀏覽器中運行簽名,並且永遠不會在任何地方傳輸秘密。您可以透過開啟瀏覽器來確認這一點'產生令牌時的網路標籤:沒有請求。這比聽起來更重要,因為將現場製作的簽名秘密貼到電話回家的隨機網路工具中會將金鑰交給您的身份驗證。
RS256 和 ES256(非對稱演算法)的工作方式不同:私鑰符號和匹配的公鑰進行驗證。當許多服務需要驗證令牌但只有一種服務能夠頒發它們時,這些是正確的選擇。這個工具故意不提供它們,因為與它們簽名意味著將私鑰貼到網頁中,這是一個永遠不值得開始的習慣。
如何使用 JWT 產生器
步驟1:寫入有效負載
將您的聲明輸入為 JSON 物件。一個最小的例子是 { "sub": "1234567890", "role": "admin" }. 的 sub 索賠是主題,通常是用戶 ID。您可以新增應用程式讀取的任何自訂字段,例如 role, scope, tenant_id,或者 email. 工具將您放在這裡的任何內容完全按照書面形式保留。
步驟 2:新增時間聲明
簽發的休假和工具印章 iat 使用目前的 Unix 時間。設定以秒為單位的到期時間以新增 exp 索賠計算為現在加上該偏移量。對於十五分鐘的訪問令牌,輸入900。對於一小時的令牌,輸入3600。這些是大多數身份驗證錯誤歸結為的主張,因此正確計算它們,以自時代以來的幾秒鐘而不是幾毫秒為單位,可以消除常見的錯誤。
第三步:選擇演算法和秘密
選擇 HS256,除非您有理由使用 HS384 或 HS512。在欄位中輸入簽名秘密。然後選擇如何解釋秘密:純文字使用您輸入的 UTF-8 字節,而 base64url 和 hex 首先將字串解碼為原始位元組。這種選擇很重要,因為許多系統儲存已經以 base64 編碼的秘密,如果您將編碼的字串作為純文字提供,您將產生不匹配的簽名。
第四步:複製令牌
簽署的 JWT 會與標頭和有效負載的解碼預覽一起出現,因此您可以在使用之前確認每個聲明。複製它並將其貼到您需要的任何地方。
為什麼要手動產生令牌?
測試您的 API'快樂之路
當您編寫驗證 JWT 的中間件時,您需要一個程式碼應該接受的令牌。產生一個與驗證者使用的相同秘密簽署的有效 exp,並確認請求傳回 200。如果沒有,則錯誤位於您的驗證邏輯中,而不是令牌中。這個單一的隔離步驟是我最常聯繫工具的原因。
測試故障路徑
強大的 API 出於正確的原因拒絕正確的令牌。使用 an 產生令牌 exp 過去已經確認您傳回了正確的過期令牌錯誤。用 a 產生一個 nbf 將來測試尚未有效的路徑。產生一個帶有錯誤秘密的簽名來確認您的簽名檢查運行。這些陰性案例是未經測試而發貨的案例,生成器使它們成為三十秒的工作。
複製特定使用者的錯誤
支援報告僅針對具有特定角色的帳戶發生的問題。產生一個具有該精確度的令牌 role 索賠和受影響的用戶's sub,您可以在本地重現請求,而無需觸摸生產資料或向使用者詢問其真實的承載令牌,無論如何您永遠不應該這樣做。
播種本地發展
團隊中的新開發人員需要一個工作令牌來擊中受保護的端點,同時前端驗證仍在建置中。與當地開發秘密簽署的生成令牌會立即解鎖它們。
HS256 vs HS384 vs HS512:您應該使用哪一個?
| 算法 | 哈希 | 簽名尺寸 | 最小密鑰長度 | 什麼時候使用 |
|---|---|---|---|---|
| HS256 | SHA-256 | 32 位元組 | 32 位元組 | 預設值。快速、廣泛支援、幾乎適用於所有用途 |
| HS384 | SHA-384 | 48 位元組 | 48 位元組 | 當政策或標準需要 SHA-384 時 |
| HS512 | SHA-512 | 64 位元組 | 64 位元組 | 高安全性上下文,或當您已經在 SHA-512 上標準化時 |
實際答案是 HS256,除非外部另有要求。 RFC 7518 要求金鑰至少與雜湊輸出一樣長,因此 HS256 為 32 位元組,HS384 為 48 位元組,HS512 為 64 位元組。當您的解碼秘密短於最小值時,生成器會發出警告,因為無論演算法名稱如何,短金鑰都會削弱簽名。更長、編號更高的演算法不會修復弱秘密;重要的是適當長度的隨機秘密。
常見錯誤以及如何避免它們
最常見的是編碼引起的秘密不匹配。您的框架將秘密儲存為 base64,您將 base64 字串貼上為純文本,現在密鑰位元組與驗證者使用的不同。簽名永遠不會匹配,並且您會追逐一個幻影錯誤。透過在工具中選擇正確的秘密編碼來修復它,以便原始密鑰位元組兩面相同。
第二個是令人困惑的秒和毫秒。 RFC 7519 中的註冊時間聲明自 Unix 時代以來均以秒為單位進行測量。 JavaScript's Date.now() 傳回毫秒。如果你計算的話 exp 你自己忘記除以 1000,你的代幣似乎會在五萬年後到期,一些嚴格的驗證者會拒絕它。讓生成器計算聲明可以完全避免這種情況。
第三是將有效負載視為私有的。不是。如果您想在索賠中儲存秘密,請停止。任何擁有代幣的人都可以閱讀它。僅儲存您對代幣持有者所看到的內容,並將真正的秘密資料保存在伺服器上。
JWT 與其他工具搭配使用的地方
一旦您產生了令牌,自然的下一步就是將其讀回。這 中國航空解碼器 將任何令牌分割為其標頭和有效負載並標記過期 exp,這就是你確認生成器產生了你的意圖的方式。如果你也產生秘密,那麼 哈希產生器 計算 SHA 雜湊客戶端,並且 密碼產生器 產生一種長隨機字串,它首先構成了一個很好的 HMAC 秘密。如果您想手動了解 Base64url, Base64 編碼器/解碼器 顯示將標頭和有效負載轉換為編碼形式的相同可逆變換。當您需要隨機標識符時,請將其放入 a 中 sub 或者 jti 索賠,the uuid 生成器 以正確的格式為您提供一份。
為了更廣泛地了解為什麼基於瀏覽器的工具會阻止第三方伺服器使用敏感資料 線上工具中的資料隱私 指南解釋了客戶端模型,以及 web 開發人員工具包 匯總與令牌工作完美配對的實用程式。
伺服器如何驗證您產生的令牌?
它有助於了解另一邊發生的事情,因為它解釋了為什麼秘密和聲明必須完全正確。當您的 API 收到令牌時,像 jsonwebtoken、jose 或 PyJWT 這樣的函式庫會依序執行三件事。它將點上的令牌分開,Base64url-解碼標頭以讀取 alg. 它重新計算簽名 header.payload 使用配置的秘密並將其逐字節與簽名段進行比較。它檢查已註冊的權利要求:是 exp 過去是 nbf 未來,確實如此 iss 和 aud 符合 API 的期望。
每一張支票都會對應到生成器讓您控制的東西。如果簽名驗證失敗,則雙方的秘密或其編碼會有所不同。如果它失敗了 exp() 令牌已過期,這可能是您故意導致測試該路徑的。如果它失敗了 alg,您使用驗證器未配置為接受的演算法產生了一個令牌,這本身就是一件有用的事情。產生具有故意變化的令牌是您如何準確地映射出 API 執行哪些檢查以及它默默地跳過哪些檢查。
一句話 alg 具體標題。 RFC 7515 定義 none 作為無符號令牌的有效演算法,早期的函式庫會信任聲稱的令牌 alg: none 並完全跳過驗證。這是經典的 JWT 漏洞。現代庫預設拒絕它,但生成器提供了 none 恰好是這樣您可以在 API 上觸發未簽署的令牌並確認它是否說不。如果您的 API 曾經接受過一個,則您發現了一個嚴重的錯誤。
您應該如何處理秘密和令牌儲存?
您簽署的秘密值得與資料庫密碼一樣小心。好的 HMAC 秘密是一個長的、隨機的字串,而不是一個令人難忘的短語,因為 HMAC 安全性取決於密鑰的不可猜測。使用密碼工具產生一個並將其儲存在您的環境配置中(從不儲存在來源控制中)是基線。當您旋轉它時,請記住,與舊秘密簽署的每個令牌在驗證器切換時都會失效,這就是為什麼生產系統通常在旋轉視窗期間支援多個有效秘密。
在客戶端,您儲存成品令牌的位置與您如何簽署令牌一樣重要。一個令牌 localStorage 頁面上的任何 JavaScript 都可以讀取,因此單一跨站點腳本缺陷會為攻擊者提供有效的憑證。一個 httpOnly, Secure, SameSite cookie 對腳本來說是不可見的,腳本會以需要 CSRF 保護為代價來關閉該路徑。常見的模式是記憶體中保存的短壽命存取令牌和記憶體中較長的刷新令牌 httpOnly cookie。這些都不會改變您產生令牌的方式,但正是上下文使產生的令牌可以安全使用,而不是責任。
問號
如何產生 JWT?
將您的聲明貼上為 JSON 對象,選擇 HS256 等簽章演算法,然後輸入秘密。該工具 base64url 對標頭和有效負載進行編碼,計算 HMAC 簽名,並傳回完成的令牌供您複製。一切都在您的瀏覽器中運行。
支援哪些簽章演算法?
HS256、HS384 和 HS512,HMAC 系列,加上未簽署的 "無&引用;測試選項。 RS256 和 ES256 被故意不提供,因為它們使用私鑰進行簽名,而將私鑰貼上到網頁中是最好避免的安全風險。
我的秘密被傳送到伺服器了嗎?
不。簽名完全透過 Web Crypto API 在您的瀏覽器中運行,因此秘密和有效負載永遠不會離開您的裝置。您可以在 DevTools Network 標籤中確認這一點,並且該工具在載入後仍可離線工作。
如何設定令牌過期?
輸入以秒為單位的到期日,然後工具會新增一個 exp 聲稱等於當前時間加上那麼多秒。對於十五分鐘的令牌,輸入 900。將欄位留空以省略 exp 完全地。
為什麼秘密至少應該是 32 位元組?
RFC 7518 需要 HMAC 金鑰,其長度至少與雜湊輸出一樣長,HS256 為 32 位元組,HS384 為 48 位元組,HS512 為 64 位元組。較短的秘密會削弱簽名,因此當解碼的秘密太短時,工具會發出警告。
我可以建立一個未簽署的令牌嗎?
是的。選擇"alg none",工具會產生標頭。有效負載。帶有空簽名的令牌。這僅用於測試 API 如何處理未簽署的令牌;大多數庫預設拒絕 alg:沒有,您也應該拒絕。
產生的 JWT 是否加密?
編號 A 簽章的 JWT 是編碼的,而不是加密的:任何人都可以基於 64url 解碼標頭和有效負載並讀取每個聲明。簽名僅證明內容未更改。切勿將密碼或秘密放入有效負載中。
