JWTデコーダー

JSON Webトークンのデコードと検査

サンプルを試す

JWTトークン

ローカルで実行 · シークレットの貼り付けも安全
こちらもどうぞ:JWT Encoder

JWT(JSON Web Token)とは?

JSON Web Token(JWT)は、RFC 7519 で定義されたコンパクトでURL安全なトークン形式です。クレームのセットをJSONオブジェクトとしてエンコードし、署名——オプションで暗号化——することで、受信者がデータが改ざんされていないことを検証できます。JWTは、REST API・シングルサインオンシステム・マイクロサービス認可におけるステートレス認証の事実上の標準です。

JWTの構造:Header · Payload · Signature

すべてのJWTは、ドットで区切られた3つのbase64urlエンコードセグメントで構成されています。HeaderとPayloadは通常のJSON——誰でも読めます——で、Signatureは正しいキーでのみ検証できる暗号値です。

エンコード済みトークン

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyMTIzIiwibmFtZSI6IkFsaWNlIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzE3MjAwMDAwLCJleHAiOjE3MTcyMDM2MDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

HeaderPayloadSignature
Header
json
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
json
{
  "sub":  "user123",
  "name": "Alice",
  "role": "admin",
  "iat":  1717200000,
  "exp":  1717203600
}

JWTデコーダーを使う理由

生のJWTはランダムなテキストに見えます。このツールはHeaderとPayloadを即座にフォーマット済みJSONとして表示し、コードを1行も書かずにクレームを確認し、有効期限をチェックし、アルゴリズムの選択を監査できます。

🔍
クレームの即時確認
Payload内のすべてのクレーム——sub、iss、aud、exp、カスタムロール、権限——をワンクリックでフォーマットして表示します。
🔓
秘密鍵が不要
HeaderとPayloadは公開情報で、Signatureだけが秘密を必要とします。このツールは署名キーなしで両方をデコードします。
⏱️
有効期限とタイムスタンプの解析
Unixタイムスタンプ(exp、iat、nbf)は自動的に人間が読める日付に変換されるため、トークンが期限切れかどうかをすぐに確認できます。
🔒
ブラウザ内で完全動作
すべてローカルで処理され、トークンデータはサーバーに送信されません。デバッグ中に本番トークンを使用しても安全です。

標準JWTクレーム参照

RFC 7519は7つの登録済みクレーム名を定義しています。必須ではありませんが、相互運用性のために使用が強く推奨されます。Payloadには任意のカスタムクレームを追加できます。

クレーム説明
iss発行者トークンを発行したエンティティを識別します——例:認証サーバーのURLまたはアプリケーション名。string
subサブジェクトJWTの対象となるプリンシパルを識別します——通常はユーザーIDまたはサービスアカウント。string
aud対象受信者想定される受信者を識別します。受信側は自身の識別子と一致することを検証する必要があります。string | string[]
exp有効期限この時刻以降はトークンを受け入れてはならないUnixタイムスタンプ。盗まれたトークンの被害を最小限にするため、必ず設定してください。number
nbf有効開始時刻この時刻より前はトークンを受け入れてはならないUnixタイムスタンプ。将来の日付のトークンをスケジュールするのに便利です。number
iat発行時刻トークンが発行されたUnixタイムスタンプ。トークンの経過時間の計算に使用されます。number
jtiJWT IDトークンの一意識別子。使用済みJTI値をサーバー側に保存・確認することでトークンの失効を実現します。string

JWT署名アルゴリズム

Headerクレームのalgは、トークンに署名したアルゴリズムを宣言します。選択はセキュリティ・パフォーマンス・サードパーティサービスが秘密鍵なしでトークンを検証できるかどうかに影響します。

アルゴリズムファミリーキータイプ備考
HS256HMACSymmetric最も一般的。共有シークレット——シークレットを持つ者は誰でも署名・検証が可能。
HS384HMACSymmetricより強力なHMACバリアント;中程度のパフォーマンスコスト。
HS512HMACSymmetric最も強力なHMACバリアント。
RS256RSAAsymmetric最も広く使われる非対称アルゴリズム(Google、Auth0、Okta)。秘密鍵なしで公開鍵により検証可能。
RS384RSAAsymmetricより高セキュリティのRSバリアント。
RS512RSAAsymmetric最も強力なRSバリアント。
ES256ECDSAAsymmetric楕円曲線——RSAより署名が短く、モバイルとIoTで人気。
PS256RSA-PSSAsymmetricRSA-PSS:PKCS1v1.5ベースのRS256より現代的で安全。
none署名なし——致命的に危険。本番環境ではalg: noneのトークンを絶対に受け入れないこと。

セキュリティ上の注意事項

JWTのデコード自体は常に安全です。適切な署名検証なしにJWTを信頼することは安全ではありません。アプリケーションでトークンを使用する際は、常にこれらのルールを念頭に置いてください。

常に安全
  • 開発者ツールまたはこのツールでJWTをデコードして検査する
  • exp、iat、nbfを使用してトークンの有効期間を理解する
  • デバッグのためにPayloadクレームをログに記録する(機密PII は除外する)
  • algヘッダーを読んでトークンの署名方法を理解する
絶対にしてはいけないこと
  • サーバー側で署名を検証せずにPayloadのクレームを信頼する
  • alg: noneのトークンを受け入れる——これは署名が全くないことを意味する
  • 高セキュリティアプリケーションでアクセストークンをlocalStorageに保存する(httpOnlyクッキーを推奨)
  • 機密権限を持つトークンのexpを遠い将来に設定する

一般的なユースケース

認証フローのデバッグ
ブラウザのネットワークタブからトークンを貼り付けて、クレームを確認し、組み込みロールを検証し、本番コードに触れることなく有効期限を確認します。
サードパーティトークンの確認
Google、Auth0、Okta、Azure ADからのトークンをすばやく読み取り、プロバイダーが含むクレームを確認し、期待するスキーマと比較します。
API開発とテスト
APIエンドポイントの作成やテスト時に、認証ヘッダーをデコードして、トークン生成ロジックがsub、aud、scopeの値を正しく設定していることを確認します。
マイクロサービス認可
サービスメッシュでは、各サービスがアップストリーム呼び出し元のJWTを検証します。トークンをデコードして、どのサービスがトークンを発行し、どの権限を主張しているかを追跡します。
サポートとインシデント対応
ユーザーが認証エラーを報告した場合、トークンをデコードして、期限切れかどうか、対象受信者が間違っているか、必要なクレームが欠けているかを確認します。
セキュリティ監査
アルゴリズムの選択、有効期限のウィンドウ、機密データが誤って暗号化されていないPayloadに保存されていないかどうかを確認し、サービス全体のJWT使用状況を監査します。

コードでのJWTデコード

HeaderとPayloadはbase64urlエンコードされています——エンコードを逆にするだけです。base64urlは+を-に、/を_に置き換え、=のパディングを省略します。Signatureだけが秘密鍵を必要とします。

JavaScript (browser)
function decodeJWT(token) {
  const [, payload] = token.split('.')
  const json = atob(payload.replace(/-/g, '+').replace(/_/g, '/'))
  return JSON.parse(json)
}
Node.js
const [, payload] = token.split('.')
const decoded = JSON.parse(
  Buffer.from(payload, 'base64url').toString()
)
Python
import base64, json

def decode_jwt(token):
    payload = token.split('.')[1]
    padding = '=' * (-len(payload) % 4)
    return json.loads(base64.urlsafe_b64decode(payload + padding))
CLI (bash + jq)
TOKEN="eyJhbGc..."
echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/null | jq .

よくある質問

秘密鍵なしでJWTをデコードできますか?
はい。JWTのHeaderとPayloadは単にbase64urlエンコードされたJSON——暗号化されたものではありません。誰でもデコードして読むことができます。シークレット(RS/ESアルゴリズムの場合は秘密鍵)は、トークンが改ざんされていないことを確認するSignatureの検証にのみ必要です。
JWTをデコードするとSignatureが検証されますか?
いいえ。デコードはクレームを読み取るだけです。検証は正しいキーを使って暗号署名を確認する別のステップです。アプリケーションでクレームを信頼する前に、必ずSignatureを検証してください。
HS256とRS256の違いは何ですか?
HS256は発行者と検証者の間で共有される単一の対称シークレットを使用します——シークレットを持つ者は誰でもトークンの作成と検証が可能です。RS256は非対称鍵ペアを使用します:秘密鍵で署名し、公開鍵で検証します。RS256では公開鍵を配布することで、外部サービスがトークンを偽造する能力なしに検証できます。
base64デコードが失敗することがあるのはなぜですか?
JWTはbase64urlエンコードを使用し、+の代わりに-、/の代わりに_を使用し、=パディング文字を省略します。標準のbase64デコーダーは+と/を必要とし、パディングが必要な場合があります。手動でデコードする前に、パディングを追加(=で4の倍数に)し、文字を置換してください。
本番環境のJWTをこのツールに貼り付けても安全ですか?
はい——このツールはブラウザ内で完全に動作し、サーバーにデータを送信しません。ただし、画面やブラウザの履歴を見られる可能性がある場合は注意してください。高度に機密性の高いトークンの場合は、ターミナルでローカルにデコードしてください。
alg: noneは何を意味し、危険ですか?
alg: noneはトークンに暗号署名がないことを意味します——誰でも任意のクレームを持つトークンを作成し、algをnoneに設定できます。初期のJWTライブラリの一部がこれらのトークンを受け入れ、重大な脆弱性を生み出しました。安全なJWTライブラリは、明示的に設定されない限り、常にalg: noneのトークンを拒否します。このチェックを無効にしないでください。