JWT 解碼與驗證
貼上一個 JSON Web Token，像你的伺服器應該做的那樣讀它：頭部與載荷解碼成可讀的 JSON，時間宣告畫成時間線——簽發、自何時有效、到期、已到期——並且對 HS256、HS384 和 HS512，用你提供的金鑰做真正的簽名驗證。一切都在你的瀏覽器中進行。權杖是憑證，而在本網站，憑證不會被貼進有紀錄的 AI 對話或陌生人的伺服器。
權杖是什麼，解碼能證明什麼
JWT 是三段以點連接的 Base64URL：命名簽名演算法的頭部、裝著宣告的載荷、以及對前兩段的簽名。中間那段——人人都想讀的那段——是編碼，不是加密：Base64 解碼器不需要任何金鑰就能打開它，這正是權杖絕不能裝任何你不會印在海報上的東西的原因。簽名添加的是出處證明：改動任何一個宣告，HMAC 就不再匹配——前提是驗證方真的校驗。填滿事故報告的失敗是：伺服器解碼後不加驗證就信任、函式庫讓權杖自己選演算法、把「none」權杖當福音接受。本頁面複刻誠實的工作流程：全部解碼並閱讀，對照時鐘讀宣告時間線（exp 在過去意味著權杖已死，簽名多有效也一樣），重視演算法警告，最後才驗證——在本機驗證，金鑰與權杖待在同一個瀏覽器分頁裡。如果你偵錯用的金鑰來自設定檔，.env 校驗器同樣不傳輸地檢查那個檔案；主打文章 不要讓聊天機器人碰你的金鑰 解釋了為什麼整族工作都搬進了瀏覽器。
常見問題
把正式權杖貼到這裡安全嗎？
這是網上做這件事最安全的地方，也是本工具存在的理由。解碼在本頁面程式碼裡、你的瀏覽器中進行：權杖從不傳輸、儲存或紀錄。對比一下人們實際在用的替代品——AI 對話會把談話保留在第三方的伺服器上；還有那些「線上 JWT 解碼器」，它們的伺服器能看到你貼上的一切。權杖在到期之前都是活憑證；貼到哪裡，就能從哪裡被重放。在這裡，它哪兒也不去——與 .env 校驗器相同的本機規則。
既然任何人都能解碼 JWT，為什麼這不是安全漏洞？
因為解碼從來不是保護手段。JWT 是簽過名的陳述，不是加密的陳述：載荷是 Base64URL——一種編碼，持有權杖的任何人都能讀——安全性在簽名裡，簽名證明陳述由持金鑰者簽發且未被篡改。經典災難是開發者把載荷當秘密，或伺服器不驗簽名，讓手工改過的載荷暢通無阻。文章 Base64 不是加密 講了兩者之下的編碼混淆。
為什麼這裡能驗證 HS256，卻不能驗證我的 RS256 權杖？
HS256 是對稱的：一個共享金鑰既簽名又驗證，所以你輸入的金鑰可以用 HMAC 在本機校驗。RS256 是非對稱的：用私鑰簽名、用配套的公鑰驗證，而本頁面就得向你索要公鑰——一個邀請貼上金鑰的頁面，教的是最終以外洩私鑰收場的習慣。用簽發方發布的 JWKS 在你自己的程式碼或工具裡驗證 RS256 權杖，永遠不要把私鑰貼到任何網站或對話，包括這一個。
「alg: none」是什麼意思，為什麼是紅色警告？
它表示權杖宣告自己未簽名——而尊重這一宣告的伺服器會接受任何人的任何載荷，無需金鑰。這是一個真實且反覆出現的漏洞類別：信任權杖自身 alg 欄位的函式庫，會被遞上一個載著管理員載荷的「none」權杖。警告之所以刺耳，是因為正確的反應就該刺耳：none 權杖是未經驗證的資料，任何接受它的系統在設計上就存在認證繞過。
簽名驗證通過了，我就完事了嗎？
你證明了權杖由金鑰持有者鑄造且內容未改。你還沒有證明它是給你的（檢查 aud 宣告）、它是現行有效的（上方時間線顯示 exp 與 nbf），或者金鑰本身足夠強——用「secret」這種可猜金鑰的 HS256 會被離線暴力破解，之後任何人都能鑄造能通過你校驗的權杖。驗證是稽核中的一行，不是整個稽核。