JWT 生成器
建立 JSON Web Token，自訂 Header 和 Payload
什麼是 JWT？
JWT 產生器用於根據 Header、Payload 和簽章設定建立 JSON Web Token。JWT 由三個 Base64URL 編碼部分組成，常用於在服務之間傳遞使用者 ID、角色、過期時間、簽發方、受眾等 claims。這個工具適合 API 測試、本地開發、教學、除錯和快速產生範例令牌。但產生出的 token 是否可信，取決於金鑰管理、演算法選擇、過期時間和伺服器端驗證是否正確。不要把真實金鑰貼到公開範例裡，弱演算法或過長有效期都有風險，敏感個人或業務資料也不應直接放進未加密的 Payload。
使用方式
JWT 產生流程
- 選擇簽章演算法（預設為 HS256）
- 輸入或點選「產生」以建立簽章密鑰
- 編輯 Payload JSON，可使用快速新增按鈕加入標準聲明
- 設定簽發時間（iat）與過期時間（exp）
- 點選「產生 JWT Token」按鈕
- 複製產生的 Token 用於測試或開發
Token 安全性
- HMAC 演算法請使用高強度密鑰，RSA/ECDSA 演算法請妥善保管私鑰。
- 請設定合理的 exp、iat、issuer 和 audience 等聲明；語法正確的 JWT 仍可能有安全風險或被服務端拒絕。
使用場景
技術原理
JWT 產生與解析互為逆向：解析負責拆開三段，產生則負責組裝。核心是計算簽章段。 組裝流程：1) 建構 Header JSON，例如 {"alg":"HS256","typ":"JWT"}；2) 建構包含標準宣告與自訂宣告的 Payload JSON；3) 分別對 Header 與 Payload 做 Base64URL 編碼，得到 h_b64 與 p_b64；4) 用「.」串接 h_b64 與 p_b64，得到 input = h_b64 + '.' + p_b64；5) 依 alg 計算簽章：HMAC-SHA256/384/512(secret, input)；6) 對簽章結果再做 Base64URL 編碼；7) 最終 token = input + '.' + sig_b64。 HMAC-SHA256 簽章：以 secret 作為金鑰（建議 ≥ 32 位元組）對 input 執行 HMAC。HMAC 內部執行兩輪 SHA-256：先從 secret 衍生 ipad/opad，再計算 SHA256(secret XOR ipad || msg) XOR opad。 金鑰強度：secret 長度直接決定安全性。RFC 7518 要求 HS256 金鑰 ≥ 256 位元（32 位元組）。生產環境務必使用密碼學安全的亂數來源（例如 crypto.randomBytes），不要使用「secret」「password」「123456」之類的字串。 常見陷阱：1) alg 替換攻擊：伺服器必須嚴格驗證 alg，不能從 token 標頭讀取 alg 後再分派到對應演算法；2) 弱金鑰：過短的 secret 容易被暴力破解；3) Payload 竄改：HMAC 保證完整性，攻擊者改動 payload 後伺服器驗證會失敗；4) Token 外洩：JWT 不可撤銷，一旦外洩只能等其過期。 本工具範圍：僅產生 HS256/HS384/HS512。RS256（RSA）、ES256（ECDSA）等非對稱演算法需要發行方持有私鑰，由後端簽章服務或專用 SDK 完成，本頁不負責產生。
- HMAC-SHA256 簽名核心：HMAC(secret, header_b64 + '.' + payload_b64)，輸出 256 位元簽名並進行 Base64URL 編碼。
- HS256 金鑰長度必須 >= 32 位元組（256 位元）；建議使用 crypto.getRandomValues 或 crypto.randomBytes 產生——短金鑰容易遭受字典攻擊。
- 本工具僅產生 HMAC 系列簽章（HS256/HS384/HS512）。RS256、ES256 等非對稱演算法需要發行方持有私鑰，不在本工具產生範圍內——如需此類 token，請改用後端簽章服務或專用 SDK。
- iat/exp/nbf 都是 Unix 時間戳（秒，非毫秒）；伺服器通常要求 exp > now()、nbf <= now()、iat <= now()。
- alg=none 攻擊：在伺服器端維護允許的演算法白名單（例如 ['HS256']）；切勿從 token header 動態選擇演算法。許多 JWT 函式庫在歷史上預設允許 alg=none——這是已知漏洞。
- JWT 一旦簽發就無法撤銷——唯一的補救是等待 exp。若要主動撤銷，需維護 jti 黑名單或使用短期存取 token 搭配重新整理 token。
範例
基本 HS256 範例
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
Secret: my-super-secret-key-32-bytes-long
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4U透過 iat 與 exp 自訂有效期
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
本工具會先將 Header 與 Payload 做 Base64URL 編碼，以「.」串接，再用共用 secret 執行 HMAC-SHA256，最終輸出三段式 Token，可直接貼到 Authorization 標頭。自訂 Claims
Header: {"alg":"HS256","typ":"JWT"}
Payload: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}常見問題
JWT 是在本機產生的嗎？
是。標頭、負載與簽章都在您的瀏覽器中透過 Web Crypto API 計算。簽章用的密鑰或私鑰從不離開頁面。請把產生的 token 本身視為可能被記錄或外洩的資料，特別是當您把它貼到實際服務時。
支援哪些簽章演算法？
本工具產生 HS256/HS384/HS512（以共用密鑰為基礎的 HMAC）。RS256/RS384/RS512（RSA）與 ES256/ES384/ES512（ECDSA）等非對稱演算法本工具暫不產生，如需此類簽章請使用後端簽章服務或專用 SDK。生產環境請避免 alg=none：合規的驗證方都會拒絕未簽章的 token。
負載中該放什麼？
標準聲明（claim）如 sub、iss、aud、exp、iat、nbf，加上服務需要的自訂聲明。負載要保持精簡——JWT 會在標頭中傳遞，每次請求都會增加流量。切勿在負載中放入密碼、完整信用卡號或其他機密；負載只是 Base64URL 編碼，並未加密。
如何設定到期時間？
把 exp 設為 token 應停止有效的 Unix 時間戳（單位是秒，不是毫秒）。沒有 exp 的 token 在規範上是合法的，但大多數正式服務都會要求一定要有。常見值為存取 token 5–60 分鐘、刷新 token 7–30 天。
為什麼產生的 JWT 驗證失敗？
常見原因：標頭中的 alg 與驗證端期待的不一致；密鑰或金鑰不同；負載聲明（iss、aud）與伺服器設定不符；簽發端與驗證端的時鐘偏差超過容許值（通常 ±60 秒）；手動編輯破壞了 Base64URL 編碼（請勿插入換行）。
我的密鑰或私鑰會被傳到伺服器嗎？
不會。簽章完全在瀏覽器中透過 Web Crypto 進行。話雖如此，仍切勿把正式環境的簽章金鑰貼進任何網頁工具——請先用非正式金鑰測試，再到您的實際後端做簽章。
我該用 HS256 還是 RS256？
HS256 需要雙方共享同一個密鑰，因此只適合簽發與驗證都由同一個服務完成的情境。RS256（或 ES256）讓簽發端保留私鑰、所有消費端都用公鑰驗證——這是 OAuth/OIDC 與任何多服務架構的正確選擇。 本工具僅產生 HS 系列 token；如需 RS256/ES256，請使用後端簽章服務或專用 SDK。