JWT Decoder, Parser and Claims Inspector

JSON Web Tokenを貼り付けて、ヘッダーとペイロードを即座にデコードし、登録されたクレームを検査し、期限切れトークンを見つけ、認証フローをデバッグするためにクリーンなJSONをコピーします。

JSONヘッダー、ペイロード、クレームをデコードするためにトークンを貼り付けてください。

デコードはブラウザセッション内で実行されます。セキュリティポリシーで許可されている場合を除き、本番環境のシークレットをツールに貼り付けないでください。

ヘッダー

{}

ペイロード

{}

署名

署名セグメントがありません
Zoom 100%
ユーティリティスタジオ

このユーティリティをあなたのサイトに追加しませんか?

WordPress、Notion、またはご自身のサイト向けに、カラーとダークモードをカスタマイズできます。

よくある質問

JWTをデコードすることでトークンが有効であることを証明できますか?

いいえ。デコードはbase64urlエンコードされたヘッダーとペイロードを明らかにするだけです。トークンが信頼できるのは、アプリケーションまたはIDプロバイダによって署名、発行者、オーディエンス、有効期限、および関連クレームが検証された後だけです。

このJWTデコーダをアクセストークンとIDトークンに使用できますか?

はい。このデコーダは、標準の3部構成のJWT形式を使用している限り、OAuthアクセストークン、OpenID Connect IDトークン、セッショントークン、サービス間トークンの検査に役立ちます。

署名パネルがトークンを検証しないのはなぜですか?

JWT検証には、正しいシークレット、公開鍵、またはJWKS設定が必要です。このツールは、可視の署名文字列が有効性の証明であるかのように装うことなく、開発者がトークンの内容を確認できるように、意図的にデコードと検査に焦点を当てています。

JWTをデバッグする際に最初に何をチェックすべきですか?

exp、nbf、iss、aud、algから始めます。実際の本番環境の問題のほとんどは、期限切れトークン、クロックスキュー、誤ったオーディエンス値、予期しない発行者URL、または安全でないアルゴリズムの仮定に起因します。

# セキュリティコンテキストを失わずにJWTをデコードする

JSON Web Tokenはコンパクトに見えますが、署名アルゴリズム、発行者、オーディエンス、サブジェクト、発行時刻、有効開始時刻、有効期限、アプリケーション固有の認証クレームなど、認証失敗を説明する正確な詳細を含んでいることがよくあります。このJWTデコーダ、パーサ、クレームインスペクタは、3つのトークンセグメントを読み取り可能なJSONに変換し、認証フローをより速くデバッグできるようにします。

デコード済みは信頼済みを意味しません

警告
誰でもJWTをbase64urlデコードできます。信頼が始まるのは、アプリケーションが正しいシークレット、公開鍵、またはJWKSで署名を検証し、発行者、オーディエンス、有効期限、およびドメイン固有のクレームを検証した後だけです。このツールはデータの検査に使用し、トークンを本物として受け入れるために使用しないでください。

# 各JWTセグメントが教えてくれること

セグメント 一般的な内容 デバッグの価値
ヘッダーアルゴリズム、トークンタイプ、オプションのキーIDHS256、RS256、ES256など、どの検証戦略をトークンが期待しているかを示します。
ペイロード登録クレームとアプリケーションクレームID、テナント、スコープ、ロール、有効期限、オーディエンスの不一致を明らかにします。
署名base64urlエンコードされた暗号署名バイト署名セグメントが存在することを確認しますが、別の場所で正しいキーで検証する必要があります。

# 認証の不具合を通常説明するクレーム

  • exp: トークンの有効期限が切れている場合、更新ロジックまたはクロック設定が間違っている可能性があります。
  • nbf: トークンがまだ有効でない場合、サーバーとIDプロバイダのクロックが同期していない可能性があります。
  • iss: 発行者URLが設定と異なる場合、トークンが間違ったテナントまたは環境から来ている可能性があります。
  • aud: オーディエンスがAPI識別子と一致しない場合、トークンは別のリソース用に発行されています。
  • alg: アルゴリズムが予期しない場合、検証ツールがトークンを拒否するか、危険な設定ミスを露呈する可能性があります。

# 開発中のJWTパーサのユースケース

フロントエンドデバッグ

ログイン後に受け取ったIDトークンとアクセストークンを検査し、スコープ、ロール、プロフィールクレームを確認します。

  • プロフィールクレームをチェック
  • スコープとロールを確認
  • ログイン環境を比較

バックエンドAPI QA

期待される発行者とオーディエンスの値を、Authorizationヘッダーで実際に送信されたトークンと比較します。

  • オーディエンスの形式を検証
  • 発行者の不一致を見つける
  • ベアラートークンを検査

IDプロバイダ設定

Auth0、Azure AD、Cognito、Keycloak、またはカスタムプロバイダからのクレームが、アプリが期待する形状になっているか確認します。

  • テナントデータを確認
  • カスタムクレームをチェック
  • プロバイダマッピングを比較

# このインスペクタで明らかになる一般的なJWTの失敗

迅速なチェック vs 信頼の判断

メリット
  • 不正な形式のトークンを即座に確認できます。
  • Unixタイムスタンプクレームを読み取り可能な日付に変換します。
  • 発行者、オーディエンス、サブジェクト、タイプの欠落値を見つけます。
デメリット
  • 期待するオーディエンスや発行者を知ることはできません。
  • 実際のキー素材なしでは署名を検証できません。
  • スコープとロールがアプリケーションにとって安全であることを証明できません。

ベストプラクティスワークフロー

クライアントまたはAPIが実際に受け取った内容を理解するためにトークンをデコードします。
アプリケーションロジックを追う前にexp、nbf、iss、aud、sub、algをチェックします。
署名と信頼の判断は認証レイヤーでのみ検証します。
機密性の高い本番JWTをチケット、ログ、スクリーンショットで共有しないでください。

参考文献