JWTデコーダー
JSON Web Tokenをブラウザ内で検査。デコード済みヘッダー・ペイロード・署名・相対タイムスタンプ付きの人間可読クレームを表示。トークンは端末外に出ません。
JWTとは？
JSON Web Token (JWT) は署名付きクレームを2者間でやりとりするコンパクトかつURLセーフな方式。OAuth/OpenID、SPA→API認証、マイクロサービス間信頼で広く使われます。
JWTには何が含まれる？
3つの部分。ヘッダー：アルゴリズム（HS256、RS256など）とトークン種別を宣言。ペイロード：サブジェクト・有効期限・カスタムデータなどのクレーム。署名：最初の2部分に対する暗号証明。
JWTとセッショントークン
JWTはユーザーIDをトークン内に保持するためサーバー側のセッション参照が不要。セッショントークンは不透明IDでサーバー側状態にマップ。JWTはスティッキーセッション無しで水平スケール、セッションは取り消しに強い。
生のbase64デコードが必要なら、Base64エンコーダーをご利用ください。
主な用途
- OAuth/OIDCデバッグ: Auth0、Okta、Cognitoなどから返されるアクセス・IDトークンを検査。
- API認証トラブル対応: 401発生時、Authorizationヘッダーのトークンをデコードしてexpとaudienceをチェック。
- SSO統合: SAML/OIDC設定変更前に、IdPが実際に発行しているクレームを検証。
- マイクロサービス信頼検証: 下流伝播前に内部サービストークンが正しいサービスIDクレームを持つか確認。
- Postman/Insomniaデバッグ: コレクション変数のトークンを貼り付けてテスト前に正しいテナントか確認。
- モバイルアプリトークン検査: mitmproxy/Charles Proxyで取得したトークンをデコードしてプッシュ通知の件名やプラットフォームクレームを検証。
- コードレビュー: PRや単体テストのサンプルトークンを点検 — expは5分か5日か？subにPII漏洩は？
FAQ
JWTとは？
JSON Web Tokenは2者間でクレームを表現するコンパクトかつURLセーフな方式で、RFC 7519で定義されています。
JWTは暗号化されている？
いいえ — デフォルトではJWTは署名されますが暗号化されません。ヘッダーとペイロードはbase64url JSONで、トークン保有者は誰でも読めます。機密性が必要ならJWE（RFC 7516）を使用。
base64urlとbase64の違いは？
base64urlはURLセーフな変種（RFC 4648 §5）。+ と / を - と _ に置換し、末尾の = パディングを省略。JWTはURLやHTTPヘッダー内を安全に通すためこれを使用。
なぜこのツールは署名を検証しない？
署名検証には署名鍵が必要 — 本番鍵をブラウザツールに貼り付けることは最悪の行為です。意図的に検証機能を除外しています。サーバー側ライブラリを使用してください。
JWTとセッション、どちらをいつ使う？
JWTはステートレスマイクロサービスやモバイルクライアントに最適。セッションは伝統的Webアプリで簡単。実際のシステムでは両方を組み合わせることが多い。
数字で見る
- JWTはRFC 7519（2015年5月）で、2者間でクレームを表すコンパクトかつURLセーフな手段として定義
- JWTはデフォルトで暗号化されません — 保有者は誰でもペイロードを読めます。機密性が必要ならJWE（RFC 7516）を使用
- 署名はJWS（RFC 7515）を使用 — 共有秘密のトークンには通常HMAC-SHA256（HS256）、非対称検証にはRSA-SHA256（RS256）
- JWT内で使用するbase64urlはRFC 4648 §5で定義されたURLセーフ変種 —
+//を-/_に置き換え、パディングを省略