JWT デコーダー オンライン: トークンをデコードして、検査し、実際に理解する

昨年の春、ユーザーは Toolz.dev からログアウトし始めました。時々ではありません - 絶えず。サインインし、1 つのツールをクリックし、ブーム: ログイン画面に戻ります。バックエンドは 15 分間のアクセス トークンと 7 日間のリフレッシュ トークンを発行し、I'd はそのフローを 100 回テストしました。そこで当然、リフレッシュ エンドポイントが壊れていると思い込み、何も問題のない Express ミドルウェアを読んで 1 時間 40 分を費やしました。

それから私はついに明白なことをしました。 認証ヘッダーからライブ アクセス トークンを取得し、デコーダに貼り付けて、クレームを調べました。 ザ・ exp 大丈夫でした。 ザ・ iat 大丈夫だった トークンはさらに14 分間有効だった つまりサーバーは大丈夫だった - そしてバグがクライアントにある必要があった 案の定: 私のフロントエンドがチェックしていた payload.exp < Date.now()。 exp エポックから秒です。 Date.now() はミリ秒です. mintされたばかりのトークンはすべて1970 年頃のどこかで期限切れになったように見えたので, クライアント " helpfully" はサーバが発言権を得る前に全員をログアウトしました. fixの3 文字 - /1000ー 2 時間近く狩りをした後.

That's the whole pitch for having a JWT decoder in your toolbox. JWTは、ラインノイズのように見えます - base64urlのちんぷんかんぷんの3 つの塊がドットで接着されています - but it' s just JSON wearing a trench coat.クレームを読める瞬間、認証バグの半分は謎ではなくなります 間違ったオーディエンス、期限切れのトークン、失われた役割、時計の歪み、ミリ秒-対秒 - they' re all sitting right there in plain text once you decode.

しかし - そしてこれは重要です - デコードが中立的な選択ではない場所 実際のアクセストークンはライブの資格情報です サーバーにトークンを出荷するデコーダサイトに貼り付けます、そしてあなた& #39; APIへの作業キーを見知らぬ人に預けただけです& #39; sリクエストログ それ& #39; s 私が構築した具体的な理由 Toolz.dev JWT デコーダ 完全にブラウザで実行します。 それについては以下で詳しく説明します。

tl;dr: JWT をオンラインでデコードするには、 Toolz.dev JWT デコーダ- ヘッダー、ペイロード、署名を瞬時に分割し、翻訳します exp/iat 人間の日付に、そして実行 100% クライアント側ので、トークンはあなたのマシンを離れることはありません. メモリに焼くことの一つ: デコードはNOT検証です. JWTは、誰でも読むことができるちょうどbase64urlエンコードされたJSONです - キーとの署名検証のみがそれを証明します& #39; s信頼できる.

主な機能

インスタント ヘッダー、ペイロード、および署名の分割

トークンを貼り付けると、デコーダはすぐにそれを 3 つの部分に分割します: ヘッダー (アルゴリズムとトークンのタイプ)、ペイロード (あなたの主張)、および署名 (エンコードされたままになります。it's は生の MAC または署名であるため、そこにあります。's は人間が読めるものではありません)。送信ボタンもページ再読み込みもありません。これは、認証ライブラリが検証前に内部で行うこと、つまり分割を正確に反映しています .、base64url-decode 最初の2 つのセグメント、parse as JSON.並べてレイアウトされたパーツを見ることは、フォーマットの直感を構築するための最速の方法です。 you& #39; llは、RS256 Auth0 トークン対HS256 Laravelトークンを一目で認識し始めます - ヘッダーは毎回それを与えます。

人間が読める経験値、IAT、および NBF のタイムスタンプ

最も便利な機能、完全な停止。 exp、 iat、そして nbf numericdate 値は Unix 時代から数秒ですが、私を含め誰も読むことができません 1783430700 そして、それが次の火曜日なのか、それとも宇宙の熱死なのかを教えてください。 デコーダは、すべてのタイムスタンプ要求を、ローカル タイムゾーンと UTC で実際の日付と時刻に変換します。 これは、従来のミリ秒-vs-seconds バグがすぐに見える場所です。デコードされた場合 exp 56,000 代の日付としてレンダリングされ、誰かが JavaScript を詰め込んだ Date.now() 秒を期待するフィールドに。 そのバグを出荷しました。 不条理な日付を見るのは診断です。 より深いタイムスタンプ考古学のために、 タイムスタンプ コンバーター 1タブ離れています。

有効期限のカウントダウンとステータス

日付をレンダリングするだけでなく、デコーダはトークンの現在の状態を示します: 有効、期限切れ、またはまだアクティブではありません (いつ) nbf は未来です。 token' s がまだ生きている場合、有効期限までのカウントダウンを取得します。これは小さな利便性のように聞こえます。 you' re 断続的な 401 をデバッグし、" リクエストが発砲されたときにこの特定のトークンは死んでいましたか?"何度もカウントダウンをサーバーと比較します' s 設定された TTL も高速に誤った設定をキャッチします - アクセストークンが 15 分間生きると想定されており、カウントダウンで 6 日が経過すると、発行コードが間違った設定値を読み取っています。

アルゴリズムとヘッダーの検査

デコードされたヘッダーはあなたを示しています alg あんど typ (プラス kid 存在する場合は友人) は、デバッグだけでなく、セキュリティに関係のある質問に答えます。 これは HS256 または RS256 のトークンですか? は kid JWKS エンドポイントが実際に提供するキーと一致しますか? そして大きなもの：それは alg 決してあってはならないこと、 none? トークンの主張 "alg": "none" テストフィクスチャか誰かが検証者を調べているかのどちらかです。どちらにしても、すぐに確認したいです。私は、単一のクレームを読む前に、最初にすべてのなじみのないトークンのヘッダーを確認します。

構文ハイライトされ、フォーマットされた JSON クレーム

生のデコードされたペイロードは、単一行の JSON ブロブであり、アイデンティティ プロバイダーは、ネストされたオブジェクト、名前空間のカスタム クレーム、スコープの配列など、それらをパックするのが大好きです。 デコーダはすべてをきれいに印刷します。構文の強調表示ですべてを印刷します。 roles、 scope、 aud 配列、および入れ子になった権限オブジェクトは実際にスキャン可能です。 同じ扱いだね JSON フォーマッタ 任意の JSON を与え、あなたの主張に自動的に適用されます。 you' が 2 つのトークンを比較すると、たとえば、1 つはエンドポイントにアクセスできるユーザーから、もう 1 つは 't - フォーマットされた出力から、目を細める練習が 10 秒の差分に変わります。

100% クライアント側 - トークンがブラウザから離れることはありません

これは機能I& #39; dのために戦います。 pastedアクセストークンはサンプルデータではありません - it& #39; sまで実際のユーザーとして認証するライブ資格情報です exp。 トークンをバックエンドに投稿するデコーダは、サーバー ログ、分析、おそらくサードパーティのエラー トラッカーに作業キーを書き込んでいます。 Toolz.dev デコーダは、すべての JavaScript で、タブでデコードを行います。 何も送信されず、何も保存されません。 私の言葉を信じないでください: devtools を開き、[ネットワーク] タブを見て、トークンを貼り付けます。 リクエストゼロ。 このアーキテクチャが、すべての機密入力ツールで重要である理由を書きました オンライン ツールのデータ プライバシーに関する私の記事。

任意のスタックから、任意の JWT で動作します

JWTは標準です - RFC 7519ーだからデコーダはdoes& #39; 誰があなたのものを鋳造したかは気にしない.auth0 とFirebaseトークンは、彼らの名前空間カスタムクレーム、Laravel Sanctum隣接セットアップ、Keycloak、Supabase、AWS Cognito、または手巻きHS256 トークンは、私自身のExpressバックエンドの兆候を Toolz.dev - if it& #39; s 3 つのbase64urlセグメントがドットで結合され、それはデコード.それは不正なフォーマットされたほぼ-JWTs を含む: セグメント2 がwon& #39; tはJSONとして解析する場合、デコーダは、サイレントに失敗する代わりに、どの部分が壊れているか教えて、それ自体が診断. truncated-on-copyトークンは、あなた& #39; dよりも一般的ですと思う.

JWT デコーダの使い方

ステップ 1: トークンをつかむ

アプリが保持する場所ならどこでもトークンを見つけます。 最も一般的なのは、DevTools → ネットワーク タブ → リクエストをクリック → コピーする Authorization: Bearer eyJ... ヘッダー値 ("Bearer" という単語なし)。 または、アプリケーション→ローカルストレージ/クッキーをチェックしてください。アプリの多くはそこにトークンを保存します。バックエンドで、それをログに記録するか、テストスイートから引き出します。文字列全体をコピーします。最後の数文字を失った JWT はまだデコードしますが、検証することはありません。そして、それと #39;s は混乱を招く時間です。あなたは 'する必要はありません。

ステップ 2: 貼り付けます

を開きます JWT デコーダ そして貼り付けます。 - ボタンなしを入力するとデコードが行われます。 you'生産トークンをどこにでも貼り付けることに不安がある場合は (良い本能)、まずネットワーク タブを開き、何も送信されないことを確認してください。 isn't。そのパラノイアチェックには 10 秒かかり、it's は、I'd が他の誰かに行うこととまったく同じです's ツール。

ステップ 3: 3 つの部分を読む

ヘッダーの先頭: 確認 alg あなたのシステムが期待していることと typ です JWT。 次に、ペイロード: iss （誰がそれを鋳造したのですか） aud （誰のためだ） sub (どのユーザー), さらにどのような役割, スコープ, またはカスタムクレームあなたのスタックが追加します. 署名はエンコードされたまま - it& #39; s 暗号出力, データではありません. ヘッダが言う場合 none、立ち止まって、何よりも前に、検証者の許可リストを確認してください。

ステップ 4: EXP とクレームを確認する

デコードされたものを見てください exp 日付と有効期限。 期限切れ? あなたの 401 があります。 有効だけど、とにかく拒否された? 今比較する aud あんど iss 検証者' s の設定に対して - 不一致には、有効期限が切れた後に 2 番目に多い原因があります。そして、タイムスタンプが 5 桁の年として表示される場合は、おめでとうございます。you' ミリ秒対秒のバグが見つかりました。ここに非常に大きなクラブへようこそ。

JWT の中身は実際には何ですか? 3 つの部分の解剖学

RFC 7519 で定義された JSON Web トークンは、ピリオドによって結合された 3 つの Base64URL エンコード・セグメントです。 header.payload.signature。 (厳密には、署名付き品種は RFC 7515 による JWS です - there's は暗号化されたいとこである JWE ですが、あなたと #39;ll が野生で出会うほぼすべてのトークンは署名付き 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 数値は次の値です: 秒 UNIX時代から。 ミリ秒ではありません。JavaScript'S Date.now() ミリ秒を返し、2 つを混乱させると、即時有効期限が切れるトークン (私の Toolz.dev ログアウト バグ) またはトークンが生成されます。 exp 事実上期限が切れることのない 56,000 年の日付。静かに、より危険な失敗です。

HS256 対 RS256。 HS256 は、共有シークレット上に HMAC で署名します。高速でシンプルですが、トークンを検証するすべてのサービスにもシークレットが保持されており、シークレットを保持している人は誰でもそのシークレットを保持できます ミント トークン。 発行者と検証者が同じプロセスである私のバックエンドのような一枚岩なら問題ありません。 RS256 は秘密鍵で署名し、公開鍵で検証します。これにより、公開鍵を (JWKS 経由で) 公開し、10 のマイクロサービスが偽造できないように検証できます。 分散システムとサードパーティの IDP は、RS256 またはその ECDSA/EDDSA 兄弟にあるべきです。

ザ・ alg: none 攻撃。 RFC 7519 により、セキュリティ保護されていない JWT が許可されます。 alg です none そして署名は空です。 初期のライブラリはヘッダーを信頼していた alg やみくもに、攻撃者が署名を剥ぎ取ったので、設定してください alg にする none、完全に攻撃者が管理する主張で検証を通過しました。 関連するトリックが RS256 を HS256 に交換するため、検証者は 公 HMACの秘密としてキー.これは、RFC 8725 - JSON Webトークンベストカレントプラクティス - が鈍い理由です: 検証者は、その許可されたアルゴリズムをコードに固定しなければならず、トークンを決して選択させない必要があります ライブラリコールdoes& #39; 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 キーなし、データなし。 #39;d は攻撃者が読み取りを気にします。ペイロードは構築により公開されています。改ざんに対して署名されており、読み取りに広く開かれています。トークン内の it's の場合、インターネット全体がそれを確認できるとします。

よくある使用例

API 開発中の 401 のデバッグ

401 はHTTPの中で最も情報量の少ないステータスコードです。 サーバーはノーと言いました - しかし、トークンは期限切れでしたか? 間違ったオーディエンス? 古いキーで署名されましたか? あなたのインターセプターがdid& #39; t火災のため完全に欠けていますか? 失敗したリクエストから実際のトークンをデコードすると、検索スペースが数秒で折りたたまれます半分の時間 exp 一人で答えます。 残りの半分、比較 iss あんど aud 検証者の環境構成に対して、ステージングに対してデブ トークンが再プレイされているか、またはその逆になります。 まさにこのループのために、デコーダを HTTP クライアントの隣に固定したままにします。これは私のコア エントリです。 API デバッグ ツールキット。最初にデコードし、次にミドルウェアを読んでください。逆の順序では 1 回あたり 1 時間 40 分かかりました。そのレッスンに興味を持ち続けるつもりです。

サプライズ ログアウトについて説明する

ユーザーが「ログアウトし続ける」と報告すると、トークンのタイムスタンプはあなたの証言です。 新しくアクセスするトークンをデコードして、そのギャップをチェック iat あんど expー それは実際にあなたが設定した15 分ですか、それとも env var で 60 秒に上書きされましたか? 次に、リフレッシュトークン& #39; s 7-dayウィンドウがあなたがそう思っているものであるかどうかを確認してください ここにも時計のスキューが表示されます: あなたの発行サーバー& #39; s クロックが数分速く実行される場合、トークンはクライアント& #39; s の計算によってすでに古代のトークンが到着します そしてもちろん、秒-vs-ミリ秒の比較バグ - ビットツールz.dev - は、完全に有効なものを見た瞬間にそれ自体を発表します exp トークンで、クライアントが誓う期限が切れています。

アイデンティティ プロバイダーがトークンに入れるものの監査

ほとんどのチームは実際に彼らのIdPのミンツ、およびit& #39; sのトークンを読んだことがない、する価値がある。 1 つを復号し、電子メール アドレス、フルネーム、映像URL、テナント識別子を見つけるかもしれない - PIIは、すべての単一のAPI要求で一緒に乗って、localStorageに保存され、トークンにその手を取得するものによって読める. Here& #39; s私の意見スタンスを、およびI& #39; lllは誰とでもそれを主張する: don& #39; tはJWTペイロードにユーザーの電子メールを置く。 sub クレームは正確に存在し、不透明な識別子を持ち、サーバー側の人的詳細を調べることができます。 クレームはすべて、ブロードキャスト中のデータと、リクエストごとに支払っているバイト数です。 デコード、監査、そして、IDP のクレーム マッピングをトリミングします。

承認デバッグ中のロールとスコープの確認

認証はあなたが誰であるか言う; 認可はあなたができること言う - そして認可が正しく行わないとき、答えはクレームにある ユーザーはそれらを誓う& #39; 管理者だが403sを得るか? 彼らのトークンをデコードする場合 role いってる user、トークンはプロモーションの前に鋳造され、彼らは再ログインする必要があります - ステートレストークンが古いスナップショットを運ぶ古典的な結果 ロールが存在しますが、アクセスがまだ失敗する場合は、正確なクレーム名と形状を確認してください: roles vs role、配列と文字列、 scope スペース区切り文字列として scp 配列として。 ミドルウェアのチェック payload.roles.includes('admin') ペイロードに対して role: "admin" 静かに、そして腹立たしく失敗します。 2 つのデコードされたトークンが並んで - 1 つは機能し、もう 1 つは機能しません - 通常、1 分以内に解決されます。

アクセスと更新トークンの内容の比較

私のようなデュアルトークン設定では、2 つのトークンが有意に異なって見えるはずであり、両方のデコードが監査です。 アクセス トークン: 短い expに加えて、API が要求ごとに必要とするすべてのクレーム。 更新トークン: 長い exp、あ jti 失効追跡のため, そして、できるだけ何も他の近くに. ifあなたのリフレッシュトークンは、役割とプロファイルデータを運んでいる, something& #39; s off - it& #39; s only ever presented to one endpoint and should& #39;t duplicate the access token& #39;s job.このサイドバイサイドチェックはまた、両方のトークンが誤って同じTTLを取得する恥ずかしいバグクラスをキャッチします, これは、あなたの" 15-minuteアクセスウィンドウ" をセキュリティシアターに回します。

JWT と不透明なセッション トークン: 正直な比較

私は Toolz.dev に JWTS を使用していますが、まだ処方されすぎていると伝えます。 取り消しの話は本当に悪いです: ユーザーを禁止すると、そのアクセス トークンは機能し続けます。 expーまさにそれが私のアクセストークンが15 分生きる理由であり、7 日間のリフレッシュトークンは私がサーバーサイドを殺すことができるものです そのハイブリッドが正直なパターンです: 安価な検証のための短命のステートレスJWT、制御のための1 つのステートフルチェックポイント。 you'reが1 つのデータベースでモノリスを実行している場合、プレーンセッションはよりシンプルで小さく、即座に取り消し可能です - 分散検証のJWT'sスーパーパワーは、あなたが持っている' の問題を解決しています。

While we& #39; re comparing - HS256 vs RS256 one glance:

よくある質問

JWT をオンライン デコーダーに貼り付けても安全ですか?

デコーダがクライアント側で実行されている場合にのみ、本物のトークンはライブ資格情報です - 誰かに送信します& #39; sサーバーは、ログに作業キーを植えます。 Toolz.dev JWT Decoderは、ブラウザですべてのデコードを行い、何も送信しません; あなたは、あなたが貼り付けている間、ネットワークタブを見て、自分でこれを確認することができます& #39; t検証するデコーダの場合、期限切れまたはテストトークンのみを使用します。

秘密なしに JWT をデコードできますか?

はい - that& #39; s the point people miss most.ヘッダーとペイロードはbase64urlエンコードされたJSONで、エンコードは暗号化ではない、誰でもキーなしですべてのクレームを読み取ることができる。 secret(または秘密キー)は署名を作成または検証するためにのみ必要である。 decodingは、何も必要としない; 信頼は検証を必要とする。

JWT のデコードと検証の違いは何ですか?

デコードは内容を読み込みます: ドットで分割、base64url-decode、json を解析します。 真正性を確認する: 秘密鍵または公開鍵を使用して署名を再計算または確認し、アルゴリズムを確認し、有効期限を確認します。 デコーダーは、トークンの主張を示します。検証のみが、キーを使用してサーバー側で行われ、それを信じるかどうかを示します。 解読されたが検証されていないクレームに基づいて承認しないでください。

JWT が無効または期限切れとして表示されるのはなぜですか?

ほとんどの場合、 exp 本気で合格しました - デコードして日付を確認してください。次に疑うのは、ずさんなコピーペーストからの切り捨てられたトークン、 aud や iss これは、検証者の構成、サーバー間のクロック スキュー、または回転したキーからの署名と一致しません。 デコードされた場合 exp 問題ないように見えますが、コードはトークンを拒否します。秒数とミリ秒を比較しているかどうかを確認してください。

JWTS は暗号化されていますか?

標準の JWT - 技術的には JWS、RFC 7515 による - は暗号化されておらず、署名されています。署名は改ざんを検出しますが、何も隠しません。ペイロードは誰でも読み取ることができます。暗号化されたバリアント (JWE) は存在しますが、一般的な Web 認証ではまれです。実用的なルール: すべての JWT ペイロードを公開として扱い、パスワード、API キー、機密データを 1 つに決して入れません。

経験値の請求はどの形式ですか?

exp RFC 7519 で定義されているように、UNIX 時代 (1970 年 1 月 1 日 UTC) からの秒数。 同じ iat あんど nbf。 従来のバグは JavaScript を使用しています Date.now()、ミリ秒を返す - どちらかの期限切れが瞬時に見えるか、または年56,000 のまわりで有効期限を運ぶトークンを作り出す 復号化されたタイムスタンプが5 桁の年を示す場合、that& #39; sあなたのバグ。

ALG なしの攻撃とは何ですか?

RFC 7519 は、セキュリティで保護されていない JWT を使用できます。 "alg": "none" そして空の署名。 古いライブラリはヘッダーのアルゴリズム フィールドを信頼していたので、攻撃者は署名を取り除き、設定を設定しました alg にする none、および偽造されたクレームで検証に合格しました。 JWT のベスト プラクティスである RFC 8725 では、検証者は、アルゴリズムの明示的な許可リストをコードに固定し、トークンが要求するものはすべて無視する必要があります。

HS256 または RS256 を使用する必要がありますか?

HS256 は署名と検証に 1 つの共有シークレットを使用します。シンプルかつ高速で、独自のトークンを発行してチェックする単一のサービスに適しています。 RS256 は秘密キーで署名し、公開キーで検証するため、多くのサービスは偽造できずに検証できます。経験則: モノリス、HS256;マイクロサービスまたはサードパーティ ID プロバイダー、RS256。

まとめ

を作りました JWT デコーダ なぜなら、私はそれを必要とし続けた Toolz.dev 自体を構築している間 - 同じ 15 分間のアクセストークンと 7 日間の更新トークン I' このガイド全体を通して解剖してきました。それは即座にデコードし、混乱の 90% を引き起こすタイムスタンプを変換し、トークンをどこにも送信しません。その最後の部分は isn't 機能チェックボックス; ライブ資格情報を処理するツールの場合、it's デザイン全体です。

トークンが毎日のデバッグの一部である場合、ネイバーもキープを獲得します。 タイムスタンプ コンバーター エポック考古学の場合、 Base64 コンバーター 生のセグメントを探している場合、 JSON フォーマッタ クレームブロブの場合、および ハッシュジェネレーター ダイジェストを扱っているとき。 より広いワークフローのために、私の API デバッグ ツール ガイド デコーダがループ内に収まる場所をカバーします。

そして、一文のバージョンをモニターにテープで留めておく: 復号はトークンの発言を示し、検証はそれを信じるかどうかを示します。 この 2 つを混乱させると、誰かのブログ投稿で最初の逸話として終わる種類のバグが出荷されます。 今回は私のものでした。