JWTトークンを安全にデコードして調査する
JSON Web Tokenの中身を正確に見ましょう:発行者、有効期限、スコープ、クレーム。ローカルでデコードし、信頼する前に期限切れや不審なトークンを見つけます。
JSON Web Token(JWT)は、ログイン後にあなたが誰であるかを証明するためにブラウザが送る文字列であり — それを持っている人は誰でも読めます。それは設計の漏れではなく、設計そのものです。本当のリスクはトークンを読むことではなく、どこで読むかです。生きたトークンを適当なデコードサイトに貼り付けると、あなたのセッションを管理できないサーバーに渡してしまいます。JWT Decoderは何もアップロードしません — header、payload、クレームをすべてブラウザ内でデコードし、そのことを前もって伝えます:入力下のセキュリティ注記は「ブラウザ内でローカルにデコードします。署名は検証されません。」と書かれています。
TL;DR
JWTは封蝕された封筒ではありません。末尾に署名が付いた3つのBase64URL部分であり、最初の2つは平文を装ったものです。
- JWTは3つの部分 —
header.payload.signature、それぞれドットで区切られます。最初の2つはBase64URLエンコードされたJSONです。 - トークンを持つ人は誰でも読める — headerとpayloadはミリ秒でデコードでき、鍵は不要です。
- 署名は完全性を証明し、機密性ではない — サーバーがトークンが改ざんされていないことを確認できるようにします。内容を隠しません。
ローカルでデコードし、トークンが何を言っているかを読み、payloadを秘密の保管場所として扱ってはいけません。
JWTの構造
すべてのJWTは、ドットで結ばれた正確に3つのBase64URLセグメントを持ちます:
<header>.<payload>.<signature>
ツール独自のサンプルトークン(サンプルボタンで読み込み)を取り、最初の2つのセグメントを見てください。ノイズに見えますが、各々は単なるBase64URLエンコードされたJSONです。デコードすると、次のように書かれています:
- Header —
{"alg":"HS256","typ":"JWT","kid":"example-demo"}。アルゴリズム、トークンタイプ、キーidを宣言します。サーバーにどう検証するかを伝えるもので、秘密ではありません。 - Payload —
{"iss":"example-app","sub":"demo-user","name":"홍길동","scope":"read write","iat":1704067200,"nbf":1704067200,"exp":4102444800}。これらはクレームです:トークンに関する記述 — 誰が発行したか、誰のためか、何を許すか、いつ切れるか。 - Signature —
demo-signature。実際のトークンでは、サーバーが秘密鍵または秘密を使ってheaderとpayloadから計算する暗号値です。ツールのサンプルは意図的にプレースホルダーを同梱しています。
headerとpayloadが読める部分です。署名は元の入力に逆変換して読むことができず、 — それは他の2つが転送中に変更されなかったことを証明するために存在し、非公開に保つためではありません。(この話のエンコード側についてはBase64エンコードと暗号化を参照 — JWTは「Base64は秘密ではない」の実例です。)
デコードされる標準クレーム
payloadはクレームの集合体です — 慣習的に決められたキー/値のペア。ほぼ毎回登場する登録済みクレームは次のとおりです。
iss(発行者) — トークンを発行した主体、通常はURLか識別子。sub(サブジェクト/主体) — トークンが誰についてか、典型的にはユーザーやアカウントid。aud(オーディエンス) — トークンが誰宛てか。課金サービス用に発行されたトークンはプロフィールサービスに拒否されるべきです。exp(有効期限) — トークンが無効になる瞬間、Unixタイムスタンプとして。確認すべき最も重要なクレームです。iat(発行時) — トークンが作成された時。nbf(この時刻以前は無効) — トークンが有効になる最も早い瞬間。iatと組み合わせて、少し先取りしてトークンを発行できます。
expが重要なのは、トークンがベアラー資格情報だからです:有効なものを提示した者が入れます。有効期限の短いトークンは、盗まれた場合の被害範囲を制限します。expがずっと先のトークンは長期間有効な鍵であり、expのないトークンは実質的に永久です。トークンが主張することを信じる前に、常に有効期限を読みましょう。
ステップバイステップ:トークンをデコードする
JWT Decoderは完全にブラウザで動きます — トークンはあなたのデバイスを離れません。手順:
- トークンを貼り付けます。 完全な
header.payload.signature文字列を JWTトークン入力 ボックスにドロップします。自分のを貼り付けずに組み込みのデモトークンを読み込むには サンプル を押します。 - デコードします。 デコード をクリックします。右側のパネルが解析結果で埋まります。(その後入力を編集すると、ステータス行は「入力が変更されました。再デコードして結果を更新してください。」となり、古い解析を読むことはありません。)
- 診断パネルを読みます。 上部にheaderから取り出した アルゴリズム、タイプ、Key ID と、各セグメントのバイトサイズを一覧します。不正または空署名のトークンはここで検出されます — ここの警告は「トークンは期限切れです。」「トークンはまだ有効ではありません。」「署名セグメントが空です。デコードは署名を検証しません。」となります。
- クレームタイムラインを確認します。 表は時間ベースのクレーム —
exp、iat、nbf— を、生の秒数、ISO UTC の読み取り、そして 有効・過去・未来 の 状態 とともに並べます。exp行が 過去 のトークンは期限切れ、nbf行が 未来 ならまだ有効でないことを意味します。 - Header と Payload パネルを読みます。 各々は コピー ボタン付きの整形JSONです。これがトークンの完全なデコードされた内容 — 発行者、件名、スコープ、すべて — です。
- 必要なものをコピーします。 1つのパネルなら コピー、header・payload・署名をまとめたテキスト要約は すべてコピー を使います。すべて消すには リセット を使います。
全体が読み取り操作です。ツールは外部を呼ばず、署名を発行者に対して検証せず、トークンを保存しません — ページを再読み込みすれば消えます。
決定的な誤解
JWTが認証に使われるため、人々はその内容が秘密だと思い込みます。違います。headerとpayloadはBase64URLエンコードされており、それはエンコードであって暗号化ではありません — 鍵なしで誰でも1ステップで元に戻せます。(これはBase64をセキュリティとして扱うのと同じ罠です;Base64エンコードと暗号化を参照。)
これには一つの鉄則があります:JWTのpayloadに秘密を絶対に入れないこと。 パスワードも、API鍵も、クレジットカード番号も、いかなる資格情報も。payloadにあるなら、公開されていると想定してください — トークンがサーバーを離れた瞬間、経路上の誰もが読めるからです。署名はトークンが変更されなかったことを保証しますが、誰が見られるかについては何も保証しません。
トークンをデコードしてpayloadがきれいに読める時、それはフォーマットが正直であることを意味します — 内容が非公開であることではありません。それに応じて設計しましょう:クライアントが必要なものだけをpayloadに入れ、本当の秘密はサーバー側に置き、短い exp 値に保護を任せましょう。
関連するチェック
デコードが最初の問いです。残りの問いには、関連するツールが答えてくれます:
- Base64部分を検証します。 各セグメントはBase64URLです — Base64 ツールで往復することを確認します。これはJWTの内容が隠されていないことを証明する方法でもあります:セグメントを貼り付け、デコードすればJSONがそのまま戻ります。
- タイムスタンプを確認します。
exp、iat、nbfはUnix秒です。タイムスタンプコンバーター で人間が読める日付に変換し、トークンがいつ切れるか、いつ有効になったかを正確に見ましょう。 - ハッシュによる完全性。 JWTの署名は改ざんされていないことを証明します。ファイルや任意の文字列で同じ仕事をするには、ハッシュ・チェックサムジェネレーター でハッシュを比較します — 一致するダイジェストは「変更なし」を意味し、鍵を交換しません。
よくある質問
JWTをデコードするのは安全ですか?
はい — JWTのデコードは、2つのJSONセグメントをBase64URLデコードするだけです。トークンが既に所有者には平文で言っていることを明らかにするだけで、トークンを弱めたり公開したり無効にしたりしません。安全でないのはどこでデコードするかです:生きたトークンを未知のウェブサイトに貼り付けるとセッションが漏れることがあります。JWT Decoder でブラウザ内にデコードすれば、トークンはデバイスを離れません。
ツールは私のトークンを読めますか?
いいえ。JWT Decoderは完全にクライアント側で動きます。トークンはブラウザのメモリで解析され、何もアップロード・記録・保存されません。入力下のセキュリティ注記が直接それを述べています:「ブラウザ内でローカルにデコードします。」ページを再読み込みすれば入力は消去されます。
ここでの「期限切れ」とは何ですか?
トークンの exp クレーム — その有効期限タイムスタンプ — が過去にあることを意味し、検証するサーバーはそれを拒否すべきです。ツールでは、期限切れトークンはクレームタイムラインで exp が 過去 と表示され、診断パネルで「トークンは期限切れです。」警告が出ます。「期限切れ」は有効性に関するもので、可読性ではありません:トークンは引き続き問題なくデコードできますが、信じるべきではありません。
トークンはどこで検証されますか?
このツールではありません。JWT Decoderはデコードします — headerとpayloadを読み、クレームタイムラインを表示します。発行者の鍵に対して署名を検証しないため、トークンが本物かは言えず、それが主張することだけを言えます。本当の検証(署名、exp、aud、発行者のチェック)は、トークンを発行または信頼するサーバー上で行われます。だからセキュリティ注記は明示的です:「署名は検証されません。」

このツールから始める
今すぐ始める