用於測試的 JWT 是一個精簡、以 HS256 簽署的權杖，由嚴格的 JSON 聲明物件與至少 32 個 UTF-8 位元組的非正式環境密鑰所構成，並編碼為三段以點號分隔的 base64url 字串。基於瀏覽器的工具會使用 Web Crypto API 在本機產生這些權杖，因此聲明與密鑰資料會停留在當前分頁中，不會離開這台機器。受保護的標頭固定為 {"alg":"HS256","typ":"JWT"}，這能避免常見的測試失敗模式——意外產生了未簽署、演算法不符或被混淆的權杖。由於 HS256 是訊息驗證碼而非加密機制，任何收到權杖的人無需密鑰即可解碼標頭與承載內容——這在測試時相當實用，因為它讓你能精確檢視驗證器將會看到的內容。簽章段只有在驗證器使用相符密鑰時，才能證明權杖在產生後未被竄改。只要謹慎使用，本機產生的測試 JWT 就能取代許多開發者為了測試授權中介層而貼到腳本中的樣板程式碼。

generate jwt for testing
在瀏覽器中產生用於測試的 JWT：HS256 權杖

為什麼開發者要在本機產生 JWT 進行測試

測試已授權的 HTTP 端點、websocket 交握或中介層鏈時，通常會需要一個語法正確且形狀正確的權杖——遠在任何身分提供者建置完成之前。以下是幾個本機產生器比啟動授權伺服器更有效率的情境：

  • 在真實 OIDC 提供者仍在建置的同時，為開發 API 模擬 bearer-token 授權。
  • 重現一個形狀類似正式環境的權杖，以對應錯誤回報，且不洩漏真實憑證。
  • 為驗證器函式庫提供預期的段長度與聲明名稱，確認其能正確解析。
  • 對速率限制器、角色型存取控制與稽核日誌形狀進行壓力測試。
  • 執行展示、工作坊與新人訓練活動時，參加者需要可運作的權杖，但又不想註冊帳號。

在這些情境中，重點在於形狀與簽章正確性，而非機密性。權杖只需要長得夠像真貨，讓你的程式碼路徑願意接受它。

HS256 測試權杖的結構

一個精簡的 JWT 是由三段 base64url 字串以點號連接而成：header.payload.signature。這些段都不會以 "=" 字元作為填充；URL 安全字母表會將 "+" 替換為 "-"，並將 "/" 替換為 "_"。產生器會將受保護的標頭鎖定為 {"alg":"HS256","typ":"JWT"}，因此第一段在每次測試執行之間都不會改變，這正是驗證器所預期的。

段內容用途
標頭 (Header){"alg":"HS256","typ":"JWT"}告訴驗證器所使用的簽章演算法
承載內容 (Payload)你的嚴格 JSON 聲明物件承載主體、受眾、到期時間及任何自訂欄位
簽章 (Signature)HMAC-SHA-256(header + "." + payload, secret)在相符密鑰下偵測竄改

承載內容是你能完全掌控的唯一段。產生器僅接受嚴格的 JSON 物件：頂層不可為陣列、不接受註解、不接受尾端逗號、不接受 undefined、不接受 NaN、不接受 Infinity，也不接受 JavaScript 運算式。其他任何內容會在簽章運算之前就被拒絕，因為寬鬆的 JSON 會在不知不覺中產生與你預期簽署內容不同的線上傳輸位元組。

如果你想窺看驗證器將會看到的內容，可以將複製的權杖貼到瀏覽器型的 JWT 解碼器 中——它會將標頭與承載內容以解碼後的物件呈現，且不會洩漏密鑰。

逐步產生測試 JWT

下列流程假設你只需要一個用於本機測試、展示或函式庫驗證的權杖——而非用於正式上線系統。

  1. 在瀏覽器中開啟 JWT 產生器。此頁面完全在用戶端執行，因此不會傳輸任何聲明或密鑰。
  2. 將一個嚴格的 JSON 聲明物件貼到聲明欄位中。例如：{"sub":"user-123","iss":"https://test.local","aud":"api-test","exp":1893456000}。
  3. 輸入至少 32 個 UTF-8 位元組的非正式環境密鑰。如果你手邊沒有，可點擊隨機按鈕——它會產生 32 個密碼學安全的隨機位元組，並以 64 個十六進位字元顯示，這些字元會直接作為原始的 UTF-8 HMAC 密鑰使用。非 ASCII 密鑰的字元數與位元組數可能不同，請預先規劃。
  4. 產生 HS256 權杖。檢視三個段，確認標頭為 {"alg":"HS256","typ":"JWT"}，確認承載內容與你貼上的內容相符，並檢查輸出中任何位置都沒有出現密鑰。
  5. 複製權杖，並使用明確指定的演算法、發行者、受眾、生命週期與金鑰政策，透過目的地的 JOSE 函式庫進行驗證。通過驗證的產生權杖，是線上格式正確的最強烈訊號。

使用你的 JOSE 函式庫驗證測試權杖

產生權杖只是工作的一半；另一半是確認你預計部署的驗證器能接受它。驗證必須明確進行，因為隱式的預設值正是演算法混淆漏洞溜進正式環境程式碼的方式。

  • 鎖定演算法。該函式庫應拒絕 HS256 以外的任何演算法，因為產生器絕不會產生 RS256、ES256、EdDSA、JWE 或未簽署的權杖。
  • 鎖定發行者 (iss) 與受眾 (aud)。像 exp 與 nbf 等 NumericDate 值是自 Unix 紀元起的秒數，而非 JavaScript 的毫秒數——這是一個常隱藏在測試固定資料中 1,000 倍的錯誤。
  • 謹慎套用時鐘誤差容忍機制。大多數函式庫預設為零；如果你設定了 leeway，請將其設為一個小的常數並加以記錄。
  • 測試一個被竄改的權杖。翻動承載段中的一個字元，重新驗證，並確認簽章檢查失敗。如果沒有失敗，表示你的驗證器設定有誤。
  • 測試一個錯誤的密鑰。用一個密鑰簽署、用另一個密鑰驗證，然後確認結果為拒絕。這能在早期抓到「測試函式庫接受任何東西」的設定錯誤。

這也是由 RFC 7515 中所述 JWS 規範所支援的維護良好的 JOSE 函式庫發揮價值的所在。驗證、演算法白名單、金鑰探索、輪替與錯誤處理屬於正式環境程式碼的責任，而非產生器頁面。

JWT 產生器能做與不能做的事

此合約刻意訂得範圍很窄，讓測試行為可預測：

  • 它僅簽署 HS256，並在標頭層級拒絕其他演算法。
  • 它會驗證嚴格的 JSON 物件聲明，並在簽署前拒絕所有其他內容。
  • 它將各段編碼為 UTF-8，並轉換為未填充的 RFC 4648 base64url。
  • 它使用瀏覽器原生的 HMAC-SHA-256 對 header + "." + payload 的精確位元組序列進行簽署。
  • 它不會自動新增 iat、exp、nbf、iss、sub、aud、jti 或任何其他聲明。這些值由你負責。
  • 它不會加密、不會產生 JWE，也不會產生 RSA 或 EC 金鑰對。
  • 它不會聯絡身分提供者、不會發布 JWK、不會儲存金鑰，也不會挑選 kid。
  • 它不會自我驗證剛建立的權杖；你需要用自己的函式庫進行驗證。

不應略過的測試安全規則

測試權杖仍然是一種 bearer 憑證，而測試的心態經常會模糊成一些在正式環境中無法存活的習慣。請將以下規則貼在鍵盤上方的牆上：

  • 在產生器頁面上僅使用非正式環境的聲明與密鑰。將隨機按鈕的輸出視為可見的開發資料，而非自動佈建的正式環境密鑰。
  • 切勿僅因為權杖已簽署，就把密碼、私鑰或個人資料放進 JWT 中。簽署並非加密；任何收到權杖的人都無需密鑰即可解碼其標頭與聲明。
  • 輪替或撤銷任何被誤貼到錯誤位置的正式密鑰或作用中的權杖。本機處理並不會讓洩漏變得無害。
  • 留意權杖的最終落點。剪貼簿紀錄、螢幕截圖、瀏覽器擴充功能、終端機日誌、客服工單與聊天討論串，都會以細微的方式洩漏 bearer 憑證。
  • 讓密鑰符合 HS256 的最低要求。32 位元組的最低限制是因為底層雜湊輸出為 256 位元；較弱的測試密鑰會產生較弱的簽章，並對驗證器給出誤導性的信心。

只要謹慎處理，由瀏覽器產生的 HS256 權杖，是確認你的授權程式碼在真實身分提供者接入之前，能正確解析、驗證並拒絕權杖的最快方法之一，而其成本僅僅是一個嚴謹的 JSON 物件與一個足夠長的密鑰。