JWTデコーダーの実際の働き
JSON Web Token（JWT）はランダムな文字が長く並んだ不透明な文字列のように見えますが、暗号化されているわけでも秘密の暗号でもありません。2者間で構造化されたデータを運ぶ、コンパクトでURL安全なコンテナです。上のデコーダーにトークンを貼り付けると、その文字列を分解し、内部の本物のJSON——メタデータ・クレーム・誰のためのトークンか・いつ期限が切れるか——を表示します。すべてはブラウザ内で完結します。トークンはアップロードされたりログに記録されたりどこかに送信されたりしません。検査しているものがライブセッションの認証情報である場合、これは非常に重要です。
3つのパートと2つのドット
適切に形成されたJWTはすべて、ドットで結合された3つのBase64urlエンコードされた文字列です：header.payload.signature。そのドット1文字が、パーサーに1つのセクションがどこで終わり次が始まるかを伝えるもので、ドットの数が間違っているトークンはそれ以外の何かが読まれる前に拒否されます。
ヘッダーはトークン自体を説明する小さなJSONオブジェクトです。ほぼ常にtyp（タイプ、通常はJWT）とalg——署名アルゴリズム（HS256（SHA-256を使用したHMAC）やRS256（SHA-256を使用したRSA）など）——が含まれます。ヘッダーは検証者に署名がどのように生成されたかを正確に伝えます。
ペイロードはほとんどの人が注目する部分です。クレーム——ユーザーとトークンに関する主張——を格納する別のJSONオブジェクトです。仕様はクレームを登録済み（標準、予約名）・パブリック・プライベート（自分のアプリ用に独自に作成した名前）に分類します。ペイロードをデコードすることで、誰がログインしているか、どのロールを持っているか、セッションがいつ失効するかがわかります。
署名は暗号化されたシールです。ヘッダーのアルゴリズムと秘密鍵または私有鍵を使用して、エンコードされたヘッダーとペイロードに対して計算されます。両方のセクションをカバーしているため、ヘッダーまたはペイロードへのいかなる変更も——文字1つでも——署名を無効にします。
最も頻繁に見かけるクレーム
登録済みクレームは異なるシステムが相互運用できるようRFC 7519で定義された短い3文字の名前です。ほぼすべての場所で見かけるものがあります。
iss— issuer（発行者）：トークンを発行したもの（認証サーバーまたはIDプロバイダー）。sub— subject（サブジェクト）：トークンが表す主体、通常は安定したユーザーID。aud— audience（オーディエンス）：トークンが宛先とする受取人。APIは自分自身がオーディエンスでないトークンを拒否すべきです。exp— expiration time（有効期限）：これ以降はトークンを受け付けてはならないUnixタイムスタンプ。iat— issued at（発行時刻）：トークンが作成されたときのUnixタイムスタンプ。
nbf（not before）とjti（一意のトークンID）にも出会うことがあります。タイムスタンプはUTCで1970年からの秒数であるため、それらを人間が読める日付として表示するデコーダーがあると、トークンがすでに期限切れかどうかを確認する暗算の手間が省けます。
デコードは検証ではない——ここが人々のはまるポイントです
この区別はJWTについて理解すべき最も重要な点です。デコードとは内容を読むことを意味します。鍵は不要で、Base64urlはエンコードであって暗号化ではないため、トークンを持っている人なら誰でもデコードできます。検証とはトークンが本物であり改ざんされていないことを証明することを意味します——正しい秘密鍵または公開鍵で署名を再計算し、一致することを確認します。
このツールはデコードを行います。トークンが何と言っているかを表示しますが、トークンが信頼できるかどうかは表示しません。トークンは偽造・期限切れ・リプレイされていても、まったく問題のないJSONとしてデコードされる可能性があります。デコードされたクレームだけに基づいて認可の判断を下してはなりません。本番環境ではサーバー側で署名を検証し、expを確認し、issとaudが期待通りであることを確認します——手作りの文字列比較ではなく、検証済みのライブラリを使って。
ペイロードは金庫ではない
ペイロードはBase64urlエンコードされているだけなので、トークンを傍受した人なら誰でも読めます。ペイロードにあるものはすべてパブリックとして扱ってください。JWTクレームにパスワード・完全なクレジットカード番号・秘密鍵・機密の個人情報は入れないでください——ここでワンクリックでデコードできるなら、コピーを入手した他の誰でも同じことができます。署名は変更からは保護しますが、読み取りからは保護しません。ペイロードの内容を本当に隠す必要がある場合は、まったく異なる仕様であるJWE（暗号化されたトークン）の仕事です。
プライバシーと関連ツール
トークンの検査は機密性の高い行為であるため、このデコーダーは完全にクライアントサイドで動作します——解析はタブ内のプレーンなJavaScriptであり、マシンの外には何も出ません。サーバーバックエンドのツールにセッショントークンを貼り付けることは、ライブな認証情報をサードパーティに渡すことを意味します——まさに避けるべきことです。基礎となるエンコーディングについてはBase64ツールをご覧ください。その他のデバイス上ユーティリティについてはデベロッパーツールを探索してください。
よくある質問
JWTは暗号化されていますか？
いいえ。標準的なJWTはBase64urlエンコードされており、暗号化されていません。トークンを持っている人なら誰でもヘッダーとペイロードを読めます。内容を隠したい場合はJWEを使用してください。
このツールは署名を検証しますか？
いいえ。ヘッダーとペイロードをデコードして表示するだけです。署名の検証には発行者の秘密鍵または公開鍵が必要であり、サーバー側で行うべきです。
ここにトークンを貼り付けても安全ですか？
はい。デコードはローカルのJavaScriptを使ってブラウザ内で完全に実行されます。トークンはアップロードされたり保存されたり、どのサーバーにも送信されたりしません。
iss・sub・aud・exp・iatは何を意味しますか？
登録済みクレームです：issuer（発行者）・subject（サブジェクト）・audience（オーディエンス）・expiration time（有効期限）・issued-at（発行時刻）。時間関連の3つはUnixタイムスタンプ（秒単位）を使用します。
デコード後に表示されるクレームを信頼できますか？
単独では信頼できません。デコードされたクレームは偽造または期限切れのトークンから来る可能性があります。クレームを信頼する前に、常にサーバー側で署名を検証し有効期限を確認してください。
なぜトークンはドットで区切られた3つのパートを持つのですか？
それらはヘッダー・ペイロード・署名であり、それぞれBase64urlエンコードされてドットで結合されています。ドットはパーサーに各セクションの開始と終了を伝えます。