去年春天,用戶開始退出 toolz。dev。有時不是 - 經常。登入、點擊一個工具、吊桿:返回登入畫面。後端發出 15 分鐘存取令牌和 7 天刷新令牌,I'd 測試了該流程一百次。所以自然地,我假設刷新端點被破壞,並花了一個小時四十分鐘閱讀沒有任何問題的 Express 中介軟體。
然後我終於做了顯而易見的事。我從授權標頭中抓取了一個即時存取令牌,將其貼到解碼器中,然後查看了聲明。這 exp 很好。這 iat 很好。令牌還有 14 分鐘有效。這意味著伺服器很好 - 並且錯誤必須位於客戶端。果然:我的前端正在檢查 payload.exp < Date.now(). exp 是紀元以來的秒數。 Date.now() 是毫秒。每個新鑄造的代幣看起來都像 1970 年左右過期了,所以客戶端 "有幫助地&引用;在伺服器有發言權之前將所有人註銷。修復的三個字元 - /1000- 經過近兩個小時的狩獵。
那'整個音調都適合在工具箱中安裝 JWT 解碼器。 JWT 看起來像線路噪音 - 三塊 base64url 胡言亂語粘在一起 - 但它'只是穿著風衣的 JSON。當你讀到聲明的那一刻,你的授權錯誤就不再神秘了。錯誤的受眾、過期代幣、缺少角色、時鐘偏差、毫秒與秒 - 它們'一旦你解碼,它們就會以純文字形式坐在那裡。
但是 - 這很重要 - 您解碼的位置不是中立的選擇。真正的存取令牌是即時憑證。將其貼上到將令牌運送到伺服器的解碼器網站中,然後您'剛剛將 API 的工作金鑰存入陌生人's 請求日誌。那'這是我建立的具體原因 Toolz.dev JWT 解碼器 完全在瀏覽器中運行。以下是更多相關內容。
TL;DR: 若要在線上解碼 JWT,請將其貼上到 Toolz.dev JWT 解碼器- 它立即分割標頭、有效負載和簽名,翻譯
exp/iat進入人類日期,並 100% 運行客戶端,因此令牌永遠不會離開您的機器。要燒入記憶體的一件事是:解碼不是驗證。 JWT 只是一個基於 64url 編碼的 JSON,任何人都可以讀取 - 只有帶有密鑰的簽名驗證才能證明它'值得信賴。
主要特點
即時標頭、有效負載和簽名分割
貼上令牌,解碼器立即將其分成三個部分:標頭(演算法和令牌類型)、有效負載(您的聲明)和簽名(左編碼,因為它'是原始MAC 或簽名- 那裡&# 39;那裡沒有人為可讀)。沒有提交按鈕,沒有頁面重新載入。這完全反映了驗證前您的 auth 庫在內部所做的事情:分割開 .,base64url-解碼前兩段,解析為 JSON。並排排列的部件是為格式建立直覺的最快方法。幾十個令牌之後,you'將開始一目了然地識別 RS256 Auth0 令牌與 HS256 Laravel 令牌 - 標頭每次都會洩露它。
人類可讀的 exp、iat 和 nbf 時間戳記
最有用的功能是句號。 exp, iat, 和 nbf 是 NumericDate 值(Unix 時代以來的幾秒),沒有人(包括我自己)可以閱讀 1783430700 並告訴你這是否'下週二還是宇宙的熱寂。解碼器將每個時間戳聲明轉換為當地時區和 UTC 中的實際日期和時間。這就是經典的毫秒與秒錯誤立即可見的地方:如果您的解碼 exp 渲染為 56,000 多年的日期,有人塞滿了 JavaScript Date.now() 進入一個需要秒數的欄位。 I'已經發貨了那個錯誤。看到荒謬的日期就是診斷。為了更深入的時間戳考古學, 時間戳轉換器 距離只有一小段路程。
到期倒數計時和狀態
除了渲染日期之外,解碼器還會告訴您令牌's 目前狀態:有效、過期或尚未啟動(何時) nbf 是將來)。如果令牌'仍然存在,您將獲得到期倒數計時。這聽起來像是一個小方便,直到您'重新調試間歇性 401 並需要回答 "當請求觸發時,這個特定令牌是否已死? & 引用;一遍又一遍。將倒數計時與您的伺服器進行比較'配置的 TTL 也會快速捕獲錯誤配置 - 如果您的存取令牌應該有效 15 分鐘並且倒數計時顯示為 6 天,則您的發布程式碼讀取了錯誤的配置值。
演算法和標頭檢查
解碼後的標頭向您顯示 alg 和 typ (加 kid 還有朋友(當在場時),它回答了對安全重要的問題,而不僅僅是調試。這是 HS256 令牌還是 RS256 令牌?是 kid 匹配您的 JWKS 端點實際服務的金鑰?最大的一個:是 alg 它永遠不應該是這樣的東西,例如 none?代幣聲稱 "alg": "none" 要嘛是測試裝置,要嘛是有人探測你的驗證者--無論哪種方式,你都想立即看到它。在我閱讀單一聲明之前,我首先檢查每個不熟悉的令牌上的標題。
語法突出顯示、格式化的 JSON 聲明
原始解碼有效負載是單行 JSON 斑點,身份提供者喜歡打包它們:嵌套物件、命名空間自訂聲明、範圍數組。解碼器會以語法突出顯示的方式列印所有內容 roles, scope, aud 數組和嵌套權限物件實際上是可掃描的。它'是相同的處理 json 格式化程式 給出任意 JSON,自動應用於您的索賠。當你'比較兩個令牌 - 例如,一個來自可以存取端點的用戶,另一個來自可以't - 格式的輸出將瞇眼練習變成十秒差異。
100% 客戶端 - 您的代幣永遠不會離開瀏覽器
這是 I'd 爭奪的功能。貼上的存取令牌不是樣本資料 - it's 即時憑證,可驗證真實使用者身分 exp。 任何將令牌發佈到後端的解碼器都剛剛將工作金鑰寫入伺服器日誌、分析,也許還有第三方錯誤追蹤器。 toolz。dev 解碼器在您的標籤中以 JavaScript 進行所有解碼。什麼都沒有被傳輸,什麼也沒有被儲存。 Don'相信我的話:打開 DevTools,觀看網路選項卡,貼上令牌。零請求。我寫下了為什麼這個架構對於每個敏感輸入工具都很重要 我關於線上工具中資料隱私的文章.
適用於任何 JWT、任何堆疊
JWT 是一個標準 - RFC 7519- 所以解碼器不'關心誰鑄造了你的。 Auth0 和 Firebase 代幣及其命名空間自訂聲明、Laravel Sanctum 相鄰設定、Keycloak、Supabase、AWS Cognito 或手捲 HS256 代幣我自己的 Express 後端標誌 for toolz。dev - 如果它'三個由點連接的 base64url 段,它解碼。其中包括格式錯誤的幾乎 JWT:如果段二獲勝且#39;解析為 JSON,解碼器會告訴您哪個部分損壞而不是默默失敗,這本身就是診斷性的。複製時截斷的令牌比您更常見'會想。
如何使用 JWT 解碼器
第一步:拿走代幣
在應用程式保留的地方尋找令牌。最常見的是:DevTools → Network tab → 點擊請求 → 複製 Authorization: Bearer eyJ... 標頭值(不含單字 "Bearer")。或檢查應用程式 → 本地儲存/Cookie,因為大量應用程式將令牌藏在那裡。在後端,記錄它或從測試套件中拉出它。複製整個字串 - 丟失最後幾個字元的 JWT 仍然會解碼但永遠不會驗證,並且 '這是一個令人困惑的時刻,你不知道'不需要。
第 2 步:將其貼上
打開 中國航空解碼器 並貼上。解碼發生在您鍵入時 - 無按鈕。如果您'對於將生產令牌貼到任何地方感到緊張(本能良好),請先打開網路標籤並確認沒有傳輸任何內容。它是't。偏執檢查需要十秒鐘,並且它'這正是 I'd 對其他人所做的事情's 工具。
第三步:閱讀三個部分
標題第一:確認 alg 這就是您的系統所期望的 typ 是 JWT. 然後有效負載: iss (誰鑄造的), aud (誰's for), sub (哪個使用者),加上您的堆疊添加的任何角色、範圍或自訂聲明。簽名保持編碼 - it's 加密輸出,而不是資料。如果標題說 none,停下來檢查一下您的驗證器's 允許清單優先於其他任何內容。
步驟 4:檢查 exp 和咬合索賠
看看解碼了 exp 日期和到期狀態。過期了?那裡'是你的 401。有效但無論如何都被拒絕了?現在比較 aud 和 iss 反對您的驗證器'配置 - 不匹配是到期後第二常見的原因。如果任何時間戳記呈現為五位數的年份,恭喜:you'發現毫秒對秒錯誤,我特此歡迎您來到一個非常大的俱樂部。
什麼'實際上在 JWT 內?三個部分的解剖
RFC 7519 中定義的 JSON Web 令牌是三個以週期連接的基本 64url 編碼的段: header.payload.signature. (嚴格來說,簽名品種是 RFC 7515 下的 JWS - 其中'是加密的表親 JWE,但幾乎每個你在野外遇到的令牌都是簽名 JWS。)
關鍵字是 編碼。 Base64url 是一種傳輸編碼 - 一種使位元組 URL 安全的可逆方式 - 而不是加密。任何持有 JWT 的人都可以讀取標頭和有效負載中的所有內容,其中零密鑰、零秘密、零努力。玩原始編碼 Base64 轉換器 你'會看到它'是標準字母表 + 和 / 換了 - 和 _,填充掉了。我在 中寫了更多關於編碼本身的內容 Base64 編碼指南.
解碼典型的標頭,您會得到:
{ "alg": "HS256", "typ": "JWT" }
根據註冊權利要求 RFC 7519 建構的有效負載定義:
{
"iss": "https://toolz.dev",
"sub": "user_8f3a2c",
"aud": "toolz-api",
"exp": 1783431600,
"nbf": 1783430700,
"iat": 1783430700,
"jti": "b4d1f0e2"
}
iss 是發行人, sub 主題(通常是您的使用者 ID), aud 目標受眾, jti 唯一的令牌 ID。 exp, nbf, 和 iat 是 NumericDate 值: 秒 自 Unix 時代以來。不是毫秒。 JavaScript's Date.now() 傳回毫秒,混淆兩者會產生立即過期的令牌(我的 toolz。dev 登出錯誤)或令牌 exp 56,000 年的日期實際上永遠不會過期--這無疑是更危險的失敗。
HS256 與 RS256。 HS256 透過共享秘密與 HMAC 簽署 - 快速、簡單,但驗證令牌的每項服務也持有該秘密,任何持有該秘密的人都可以 薄荷 代幣。對於像我的後端這樣的整體來說很好,其中發行者和驗證者是相同的過程。 RS256 使用私鑰進行簽名並使用公鑰進行驗證,因此您可以發布公鑰(透過 JWKS)並讓十幾個微服務進行驗證,而它們中的任何一個都無法偽造。分散式系統和第三方 IDP 應位於 RS256 或其 ECDSA/EdDSA 兄弟系統上。
的 alg: none 攻擊。 RFC 7519 允許無擔保 JWT alg 是 none 簽名是空的。早期的庫信任標頭和#39;s alg 攻擊者盲目地剝離了簽名,設定 alg 到 none,並透過完全攻擊者控制的主張進行驗證。相關的技巧將 RS256 替換為 HS256,因此驗證者使用 公眾 作為 HMAC 秘密的密鑰。這就是為什麼 RFC 8725 - JSON Web 令牌當前最佳實踐 - 是直截了當的:驗證者必須將其允許的演算法固定在程式碼中,並且永遠不要讓令牌選擇。如果您的庫呼叫不't 包含明確的內容 algorithms 列表,今天修復它。
解碼與驗證-重要的路線。 解碼就是閱讀;驗證就是信任。代碼的差異:
// Decoding: no secret, no trust. Anyone can do this.
const payload = JSON.parse(
Buffer.from(token.split('.')[1], 'base64url').toString()
);
// Verifying: proves the signature AND pins the algorithm.
const verified = jwt.verify(token, secret, { algorithms: ['HS256'] });
線上解碼器做第一件事。它可以向您顯示聲明;它不能也不應該假裝告訴您令牌是真實的。僅有的 verify,用鑰匙,就可以做到這一點。切勿根據已解碼但未經驗證的聲明做出授權決定。
這導致了最後一條規則: 切勿在 JWT 有效負載中放置秘密。 沒有密碼,沒有 API 金鑰,沒有數據,你'd 介意攻擊者閱讀。有效負載透過構造公開 - 簽署反對篡改,開放閱讀。如果's 在令牌中,假設整個網路都可以看到它。
常見用例
在 API 開發過程中偵錯 401
401 是 HTTP 中資訊最少的狀態代碼。伺服器說不 - 但令牌是否過期了?錯誤的受眾?用陳舊的密鑰簽名?完全缺失是因為您的攔截器沒有't fire?解碼失敗請求的實際令牌會在幾秒鐘內使搜尋空間崩潰。一半的時間 exp 獨自回答。另一半,比較 iss 和 aud 針對您的驗證器和#39;環境配置會發現一個開發令牌正在針對暫存重播,反之亦然。我為此循環將解碼器固定在我的 HTTP 用戶端旁邊; it'是我的核心條目 API 偵錯工具包. 先解碼,再讀中間件-相反的順序讓我花了一個小時四十分鐘一次,我打算繼續收集對該課程的興趣。
解釋驚喜註銷
當用戶報告並引用時;它不斷記錄我,"令牌'的時間戳記是您的證人陳述。解碼新的存取令牌並檢查它們之間的差距 iat 和 exp- 實際上是您配置的 15 分鐘,還是 env var 將其覆蓋到 60 秒?然後檢查刷新令牌是否和#39; 7 天視窗就是您所認為的。時鐘偏差也出現在這裡:如果您的發行伺服器'時鐘運行速度快幾分鐘,令牌已經由客戶端到達並#39;s 計算。當然,秒與毫秒的比較錯誤(咬toolz。dev 的錯誤)會在您看到完全有效的錯誤時宣布自己 exp 在令牌上,您的客戶發誓已過期。
審核您的身分提供者放入的代幣
大多數團隊從未真正閱讀過他們的 IdP 鑄幣廠的代幣,並且它'值得做。解碼一個,您可能會找到電子郵件地址、全名、圖片URL、租戶識別碼- PII 隨身攜帶在每個API 請求中,儲存在本地存儲中,並且可以被任何獲得代幣的東西讀取。這裡'我固執己見的立場,以及 I'會與任何人爭論:don't 將用戶電子郵件放入 JWT 有效負載中。這 sub 索賠的存在正是為了讓您可以攜帶不透明的標識符並在伺服器端查找人類詳細資訊。每個額外的索賠都是您的資料'正在廣播和位元組you'正在為每個請求付費。解碼、審核,然後修剪您的 IdP' 索賠映射。
在授權調試期間驗證角色和範圍
身份驗證說明你是誰;授權說明你可以做什麼 - 當授權行為不當時,答案就在聲明中。用戶發誓他們'是管理員但得到 403s?解碼他們的令牌。如果 role 說 user,代幣是在促銷之前鑄造的,他們需要重新登錄--這是無狀態代幣攜帶陳舊快照的典型後果。如果角色存在但訪問仍然失敗,請檢查確切的索賠名稱和形狀: roles vs role數組與字串, scope 作為空間分隔的字串 vs scp 作為數組。中間件檢查 payload.roles.includes('admin') 針對具有的有效負載 role: "admin" 默默地、令人憤怒地失敗。兩個並排解碼的令牌 - 一個有效,一個無效 - 通常在一分鐘內解決。
比較存取和刷新令牌內容
在像我這樣的雙令牌設定中,兩個令牌看起來應該有意義地不同,解碼兩者就是審核。存取令牌:短 exp,加上 API 根據請求需要的任何聲明。刷新令牌:長 exp,a jti 用於撤銷跟踪,並且盡可能接近其他內容。如果您的刷新令牌攜帶角色和個人資料數據,某物'關閉 - it'僅呈現到一個端點,並且應該'複製存取令牌'工作。這張並排檢查還發現了令人尷尬的錯誤類別,其中兩個令牌意外地獲得了相同的 TTL,這會將您的 "15 分鐘訪問視窗"變成安全劇院。問我怎麼知道要檢查那個。
JWT 與不透明會話令牌:誠實的比較
| JWT | 不透明的會話令牌 | |
|---|---|---|
| 無國籍狀態 | 獨立;任何具有密鑰的伺服器無需查找即可進行驗證 | 伺服器(或像 Redis 這樣的共享商店)必須查找每個請求 |
| 撤銷 | 硬 - 有效期限至 exp 除非你建立一個拒絕主義者,這會重新引入狀態 |
簡單 - 刪除伺服器端記錄,令牌立即失效 |
| 每個請求的大小 | 數百位元組到超過一千位元組,開啟 每一個 請求 | ~32 個 64 位元組 |
| 驗證發生的地方 | 任何持有(公共)密鑰的地方 - 非常適合微服務 | 會話儲存位於何處 |
| 聲稱新鮮 | 問題時間的快照;角色變更等待重新發行 | 始終當前 - 讀取即時數據 |
| 可調試性 | 立即解碼並讀取聲明 | 設計不透明;需要商店訪問 |
我將 JWT 用於 toolz。dev 和 I'仍然會告訴你它們'被過度處方。撤銷的故事確實很糟糕:當你禁止用戶時,他們的存取權杖會一直有效 exp- 這正是為什麼我的存取令牌有效期為 15 分鐘,而 7 天刷新令牌是我可以在伺服器端殺死的東西。這種混合是誠實的模式:用於廉價驗證的短命無狀態 JWT,用於控制的一個狀態檢查點。如果您'運行一個具有一個資料庫的巨石,普通會話更簡單、更小,並且可以立即撤銷 - JWT'分散式驗證的超能力正在解決您不具備的問題'沒有。
而我們'正在一目了然地比較 - HS256 與 RS256:
| HS256 | RS256 | |
|---|---|---|
| 關鍵模型 | 一個共同的秘密標誌 和 驗證 | 私鑰標誌,公鑰驗證 |
| 誰可以鑄造代幣 | 任何人都保守秘密 | 只有私鑰持有者 |
| 最適合 | 單一服務,發行人=驗證者 | 微服務、第三方 IDP、JWKS |
| 簽名大小/速度 | 更小、更快 | 分發更大、更慢、更安全 |
常見問題
將 JWT 貼到線上解碼器中安全嗎?
僅當解碼器運行客戶端時。真正的令牌是即時憑證 - 將其發送給某人'伺服器在他們的日誌中植入了一個工作金鑰。 toolz。dev JWT Decoder 在瀏覽器中進行所有解碼,並且不傳輸任何內容;您可以在貼上時透過查看網路標籤自行確認這一點。對於解碼器,您可以'僅驗證、使用過期或測試令牌。
你能無秘密地破解 JWT 嗎?
是的 - 那'這是人們最錯過的點。標頭和有效負載是 base64url 編碼的 JSON,編碼不是加密。任何人都可以讀取每個聲明,無需任何金鑰。僅需要秘密(或私鑰)來建立或驗證簽名。解碼不需要任何內容;信任需要驗證。
什麼'解碼和驗證 JWT 之間的區別?
解碼讀取內容:點分割、base64url-decode、解析JSON。驗證證明真實性:使用金鑰或公鑰重新計算或檢查簽名,確認演算法,檢查到期。解碼器向您顯示令牌聲明的內容;僅驗證(使用金鑰在伺服器端完成)即可告訴您是否相信它。切勿根據已解碼但未經驗證的聲明進行授權。
為什麼我的 JWT 顯示為無效或過期?
最常見的是 exp 已真正通過 - 解碼並檢查日期。下一個嫌疑犯:草率複製貼上截斷的令牌,an aud 或者 iss 這與您的驗證器'不匹配;s 配置、伺服器之間的時脈偏差或旋轉鍵的簽名。如果已解碼 exp 看起來不錯,但你的程式碼拒絕了令牌,檢查你是否'正在將秒與毫秒進行比較。
JWT 加密嗎?
標準 JWT(技術上是 JWS,根據 RFC 7515)是簽署的,而不是加密的。簽名偵測到篡改,但不會隱藏任何內容;有效負載可供任何人讀取。存在加密變體 (JWE),但在典型的 Web 授權中很少見。實用規則:將每個 JWT 有效負載視為公共負載,並且切勿將密碼、API 金鑰或敏感資料放入其中。
exp 索賠的格式是什麼?
exp 是一個 NumericDate:自 Unix 紀元(1970 年 1 月 1 日 UTC)以來的秒數,如 RFC 7519 中定義。相同 iat 和 nbf。 經典錯誤是使用 JavaScript's Date.now(),返回毫秒 - 產生看起來立即過期或帶有 56,000 年左右到期日期的代幣。如果解碼的時間戳顯示五位數的年份,則 ' 是您的錯誤。
什麼是無藻類攻擊?
RFC 7519 允許使用無擔保 JWT "alg": "none" 還有一個空簽名。舊庫信任標頭和#39;s 演算法字段,因此攻擊者剝離簽名,設定 alg 到 none,並透過偽造聲明進行驗證。 RFC 8725(JWT 最佳當前實踐)要求驗證者在程式碼中固定明確的演算法允許列表,並忽略令牌要求的任何內容。
我應該使用 HS256 還是 RS256?
HS256 使用一個共享的秘密進行簽名和驗證 - 簡單快速,適用於既發行又檢查自己的令牌的單一服務。 RS256 使用私鑰進行簽署並使用公鑰進行驗證,因此許多服務無需偽造即可進行驗證。經驗法則:整體,HS256;微服務或第三方身分提供者,RS256。
包裹起來
我建造了 中國航空解碼器 因為我在建立 toolz。dev 本身時一直需要它 - 相同的 15 分鐘存取令牌和 7 天刷新令牌 I'一直在閱讀本指南。它會立即解碼,翻譯導致 90% 混亂的時間戳,並且永遠不會將您的令牌發送到任何地方。最後一部分是't 功能複選框;對於處理即時憑證的工具,它'是整個設計。
如果代幣是您日常調試的一部分,鄰居也會賺取他們的保留: 時間戳轉換器 對於紀元考古學來說, Base64 轉換器 為了戳原始片段, json 格式化程式 對於索賠斑點,以及 哈希產生器 當你'正在處理摘要。為了更廣泛的工作流程,我的 API調試工具指南 覆蓋解碼器在循環中的位置。
並將一句話版本錄製到您的顯示器上:解碼告訴您令牌所說的內容,驗證告訴您是否相信它。迷惑兩人和你'將運送這種錯誤,最終成為某人的開場軼事'的部落格文章。這次是我的。
