JWT デコーダー

JSON Web Token（JWT）とは何か、なぜデコーダーが必要なのか？

JSON Web Tokenを検査・デバッグする方法

1. 1

   トークンを取得する：HTTPのAuthorizationヘッダーやブラウザのローカルストレージから、JWT文字列全体をコピーします。

2. 2

   トークンを入力する：コピーした文字列を「エンコード済みトークン」欄に貼り付けます。DevToraは長いトークン文字列も問題なく処理します。

3. 3

   ヘッダーを分析する：分離されたHeaderセクションで、署名アルゴリズム（alg）とトークンタイプ（typ）を確認します。

4. 4

   ペイロードデータを確認する：Decoded Payloadを通じて、ユーザー属性、発行者（iss）、対象者（aud）、カスタムクレームを確認します。

5. 5

   有効期限（exp）を確認する：ペイロード内のexpクレームを探し、トークンが現在有効な状態か、それとも期限切れかを確認します。

6. 6

   署名構造を確認する：署名（3番目のセグメント）の存在を確認し、トークンの整合性構造が正しいかを把握します。

7. 7

   可読性のためのフォーマット：見やすく整形されたJSONビューで、複雑にネストされたデータ構造を一目で把握できます。

8. 8

   機密情報を管理する：JWTのペイロードは誰でもデコードできるため、パスワードや機密性の高い個人情報がトークンに含まれていないか確認してください。

9. 9

   エラーメッセージのフィードバック：トークンの形式が不正または途中で切れている場合、エラーパネルから即座に原因を把握できます。

10. 10

    セキュリティ優先のデバッグ：個別のコピーボタンを使用して、必要な情報だけをローカルのデバッグログやドキュメントに安全に転記します。

エンジニアのための高度なJWT検査機能

• リアルタイムのトークン分解：入力と同時にトークンをヘッダー、ペイロード、署名の3つに論理的に分解します。
• 高品質なJSONフォーマット：生のJSONデータをインデント付きの構造化されたレイアウトに変換し、可読性を最大化します。
• 100%クライアント側での処理：トークンデータがサーバーへ送信されることはなく、ユーザーのブラウザのローカル環境でのみ処理され、完全なプライバシーを保証します。
• 正確なBase64Urlデコード：JWT標準である特殊文字（-、_）とパディング省略のルールを完全に処理します。
• 標準クレームの識別：sub、iss、iat、expなどの主要な標準クレームを明確に表示し、迅速な監査を可能にします。
• リアルタイムのエラーフィードバック：不正な形式や無効なBase64シーケンスに対して明確な警告メッセージを提供します。
• レスポンシブデザイン：スマートフォンやタブレットでも認証の問題を即座にデバッグできるよう、モバイルに最適化されたレイアウトを提供します。
• ワンクリックの部分コピー：デコードされたヘッダーとペイロードをそれぞれ個別にコピーできる便利な専用ボタンを提供します。
• ダークモード対応：長時間作業する開発者のために、プレミアムなダークモードインターフェースを完全にサポートします。
• ゼロ依存のセキュリティ：外部ライブラリに依存せずネイティブのブラウザ機能を活用し、速度とセキュリティを両立させています。
• ステートレスな動作：いかなるデータもサーバーに保存されたりログに記録されたりすることはありません。ページを更新するとすべてのデータがリセットされます。
• RFC 7519標準準拠：JSON Web Tokenの公式技術仕様を厳格に遵守し、汎用的な互換性を保証します。

JWTのセキュリティと実装時に注意すべきエラー

JWTに関する詳細なQ&A

1. 1

   オンラインで自分のJWTをデコードしても安全ですか？

   DevToraはすべてのデコードロジックをローカルブラウザ内で実行します。入力されたトークンはサーバーへ送信されないため、個人情報漏洩の心配なく安心してご利用いただけます。

2. 2

   HS256とRS256の違いは何ですか？

   HS256は対称鍵アルゴリズムで、1つの秘密鍵で署名と検証の両方を行います。RS256は非対称鍵アルゴリズムで、秘密鍵で署名し公開鍵で検証します。分散システムではRS256の方がセキュリティ上有利です。

3. 3

   JWT内部のデータを修正して再署名できますか？

   データを修正すること自体は簡単ですが、修正後に再署名するには元のトークン発行時に使用した秘密鍵（Secret）が必要です。鍵がなければ、修正されたトークンは無効として扱われます。

4. 4

   JWTは暗号化されていますか？

   いいえ、基本的にJWT（JWS）は署名されているだけで暗号化されているわけではありません。内部データはBase64Urlでエンコードされているだけで誰でも読めるため、機密情報を含めるべきではありません。

5. 5

   なぜ通常のBase64ではなくBase64Urlを使うのですか？

   Base64Urlは「+」「/」記号を「-」「_」に置き換え、URLで問題なく使用できるようにした方式です。またパディング記号（=）を省略してトークンの長さを短くします。

6. 6

   JWTに絶対に含めてはいけない情報は何ですか？

   ユーザーのパスワード、マイナンバー、クレジットカード番号のような機密データは絶対に含めてはいけません。JWTはデータの完全性を保証するものであり、機密性を保証するものではないためです。

7. 7

   JWTの有効期限はどのように処理されますか？

   ペイロードのexpクレームで有効期限を設定します。サーバーはこの時刻をチェックして無効なトークンを拒否し、一般的にリフレッシュトークンと併用してセッションを更新します。

8. 8

   JWTの「クレーム（Claim）」とは何ですか？

   トークンに含まれる情報の一片を意味します。発行者（iss）、有効期限（exp）、対象者（aud）のような標準クレームと、ユーザーが独自に定義するカスタムクレームがあります。

9. 9

   ペイロードが大きくなるとパフォーマンスに影響しますか？

   はい。JWTはリクエストのたびにヘッダーに含めて送信されるため、ペイロードが大きくなるとネットワークコストが増加します。必要最小限のデータのみを含めることがパフォーマンス最適化の鍵です。

10. 10

    JWTを即座に無効化（Revoke）できますか？

    基本的にJWTはステートレスなため、有効期限が切れるまでは有効です。即座の無効化が必要な場合は、サーバー側でブラックリストを管理するか、別のストレージを活用する必要があります。

11. 11

    ローカルストレージとクッキー、どちらに保存すべきですか？

    ローカルストレージは使いやすい反面、XSS攻撃に弱いです。HttpOnly属性を設定したクッキーはXSSから安全ですが、追加でCSRF対策が必要になります。

12. 12

    署名検証を省略するとどのような問題が起きますか？

    署名検証を行わないと、攻撃者がペイロード内のユーザー権限（例：admin: true）を自由に改ざんできてしまい、深刻なセキュリティ侵害につながる可能性があります。

13. 13

    ヘッダーの「kid」とは何を意味しますか？

    Key IDの略で、複数の鍵を使用する環境において、どの鍵でトークンが署名されたかを識別するために使用されます。鍵のローテーション時に便利です。

14. 14

    JWTのサイズに制限はありますか？

    技術仕様上の制限はありませんが、実際にはブラウザやサーバーのHTTPヘッダーサイズ制限（通常8KB〜16KB）に引っかかることがあります。この範囲を超えるとリクエストが拒否される可能性があります。

15. 15

    署名が「Invalid」と表示されるのはなぜですか？

    トークンの内容が転送中に改ざんされた場合や、検証に使用した秘密鍵が間違っている場合に発生します。また、トークンの形式が壊れている場合も署名検証に失敗します。

16. 16

    このツールについてフィードバックを送れますか？

    はい！DevToraは継続的に進化するプラットフォームです。バグ報告や機能提案がありましたら、いつでもsupport@devtora.org までご連絡ください。