JWTデコーダー
JWT 万 前 .
Header — (Base64url)
Payload — Claims (使用) (Base64url)
Signature — Header + Payload 名 (必要)
シェアする
使い方
- 1 JWTトークン全体(header.payload.signatureの3部分をドット連結)を入力欄に貼り付けます。
- 2 「デコード」ボタンを押すと、ヘッダーとペイロードがJSONで整形表示されます。
- 3 alg(アルゴリズム)・exp(有効期限)・iat(発行時刻)・sub(主体ID)が個別に表示。期限切れの場合は警告。
- 4 署名検証は本ツールでは行いません(秘密鍵が必要)。本番運用では、サーバー側で必ず署名検証してください。
JWTデコーダーについて
よくある質問
Q JWT は何のために使う?
OAuth・OpenID Connect・REST API認証で<strong>「ステートレスな認証情報」</strong>として使われます。サーバーがセッション情報を保持しなくてよく、マイクロサービス間のスケーラブルな認証に最適。例えばSPA(React/Vue)からAPIサーバーにアクセスする際、ログイン後にJWTを取得し、各リクエストで<code>Authorization: Bearer [JWT]</code>ヘッダで送信。
Q JWT は安全?
設計次第です。<strong>正しく実装されたJWTは安全</strong>(RS256・短い有効期限・HTTPS・jti管理)、誤った実装は危険(none alg許容・長い有効期限・HTTPS未使用・取消し機構なし)。OWASP JWT Cheat Sheet に詳細なベストプラクティスが書かれています。本番では検証を必ず行い、署名なしJWT(alg=none)を絶対に許容しないこと。
Q 有効期限はどれくらい?
</p><ul class="ri-ul"><li><strong>アクセストークン</strong>: 15分〜1時間(短くする方が安全)</li><li><strong>リフレッシュトークン</strong>: 数日〜数週間(長期だがDB管理で取消可能)</li><li><strong>パスワードリセット用</strong>: 15分〜1時間(超短期)</li><li><strong>OpenID Connect ID Token</strong>: 1時間が標準</li></ul><p>長すぎると盗まれた時の被害拡大、短すぎるとUXが悪化。アクセストークンを短く、リフレッシュトークンで再取得が現代的なパターンです。
Q JWTを途中で無効化する方法は?
JWTは元々ステートレス設計のため、無効化が難しいです。対策:</p><ul class="ri-ul"><li><strong>短い有効期限</strong>+リフレッシュトークン: アクセストークンを15分にすれば、最大15分で自動失効</li><li><strong>jti(JWT ID)管理</strong>: 無効化したいjtiをRedis/DBに保存して、サーバー側で確認</li><li><strong>セッションIDを併用</strong>: JWTにセッションIDを含め、セッションを削除すれば実質無効化</li></ul>
Q HS256とRS256の違いは?
</p><ul class="ri-ul"><li><strong>HS256(HMAC SHA-256)</strong>: 対称鍵 — 署名・検証で同じ秘密鍵を共有。シンプルだが、検証側にも秘密鍵が漏れるリスク。内部システム向け。</li><li><strong>RS256(RSA SHA-256)</strong>: 非対称鍵 — 署名は秘密鍵、検証は公開鍵。OpenID Connect標準で、複数サービス・公開API向け。発行側のみ秘密鍵を保持。</li></ul><p>セキュリティ的にはRS256が推奨。OAuth 2.0プロバイダー(Google・Microsoft等)はRS256を使用。
Q JWT のサイズが大きい時は?
標準的なJWTは200〜800バイト程度ですが、大きなクレーム(配列・オブジェクト・写真URL等)で5KB超になることも。HTTPヘッダのサイズ制限(8KB)に近づくと問題発生。対策: ①ペイロードを最小化、②大きなデータは別エンドポイントから取得、③Cookie保存(4KB制限)からlocalStorage(5MB)へ移行、④opaque token(ランダム文字列+サーバー側DB)に切り替え。
Q JWTをローカルストレージに保存しても安全?
XSS脆弱性があると盗まれます。安全な保存方法:</p><ul class="ri-ul"><li><strong>HttpOnly Cookie</strong>: JavaScriptからアクセス不可、XSS耐性。CSRF対策(SameSite=Strict)も必要</li><li><strong>localStorage</strong>: XSS脆弱性で盗難リスクあり、SPA・モバイルでは現実的</li><li><strong>sessionStorage</strong>: タブ閉じると消える、ページリロードでも残る</li></ul><p>Microsoft・Auth0・Authoは「短命なアクセストークンはメモリ・localStorage、長命なリフレッシュトークンはHttpOnly Cookie」推奨。
Q 本ツールで本番JWTをデコードしても大丈夫?
<strong>非推奨</strong>です。本ツールは送信されたトークンをサーバー側でパースし、ログには残しませんが、HTTPS経由でも送信は発生します。本番のリフレッシュトークン・本番ユーザーのIDトークン等の機密性高いJWTは、<strong>ローカルツール(jwt.io・jq・Postman)</strong>で検証することを推奨します。本ツールは学習・デバッグ・有効期限切れ確認等の一般用途向けです。
Q JWT と OAuth の関係は?
JWTは<strong>OAuth 2.0で使われるアクセストークンの一形式</strong>です。OAuth 2.0仕様自体はトークン形式を定義しておらず、Bearerトークン全般を扱えます。実際は: ①Opaque Token(ランダム文字列+サーバーDB管理)、②JWT(自己完結型)の2種類が主流。Google・Microsoftはリフレッシュトークンにopaqueを、IDトークンにJWTを採用。OpenID Connectは仕様上ID Tokenを必ずJWTで定義しています。