JWTをデコード
JSON Web Tokenのヘッダー、クレーム、有効期限を確認できます。トークンは有効な認証情報なので、ここでは何もどこにも送信せず、保存も一切しません。
- 保存しません
- 順番待ちなし
- 登録不要・透かしなし
トークンがこのページの外に出ることはありません。デコードはこの場で行われ、どのサーバーにもリクエストを送りません。JWTは多くの場合そのまま使える認証情報なので、これは重要です。ページの読み込み後にWi-Fiをオフにしてもデコードできます。何も送信されていないからです。
「Bearer 」の接頭辞が付いたままでも問題ありません。無視されます。
使い方
トークンを貼り付け
「Bearer 」の接頭辞は付いていてもいなくても構いません。トークンはこのページ内にとどまり、通信は行われません。
3つの部分を確認
ヘッダー、ペイロード、署名をそれぞれデコードして整形します。タイムスタンプは実際の日時になり、残り時間も表示されます。
警告を確認
期限切れのトークン、有効期限の欠如、「none」アルゴリズムなどの問題を、その意味とともに指摘します。
確認しているものと、読み取っているだけのもの
このページで行うことは、2つの日時の比較を除いてすべて書き写しです。ヘッダーとペイロードはBase64URLからデコードして表示し、署名は取り出してそのまま表示するだけで一切手を付けません。ここには鍵がなく、暗号処理はまったく行われないからです。ページが行う2つの判定は、お使いの端末の時計を基準にした計算です。 有効期限のクレームと現在時刻の比較、そして有効開始日時のクレームと現在時刻の比較です。クロックスキュー（時刻のずれ）の許容はありません。同じトークンを確認するサーバーは通常1〜2分の余裕を持たせます。時計が5分進んでいるノートパソコンでは、有効なトークンが期限切れと表示されますが、トークン自体にはまったく問題ありません。
表示される内容を左右するパース上の細部が2つあります。時刻のクレームは、JSONの数値として届いた場合にのみ読み取ります。有効期限が文字列の「1699999999」として書かれたトークンは、有効期限がまったくないものとして扱われ、自動的に期限切れにならないという警告が出ます。事実とは正反対です。また、ペイロードは当サイトのJSONツールで使っている桁を保持するパーサーではなく、ブラウザ標準のJSONパーサーで読み込むため、subjectに入ったsnowflakeのユーザーIDのような64ビットの数値クレームは、末尾の桁が丸められて表示されます。JWTの識別子が通常文字列なのはまさにこのためです。文字列でない場合は、クレームの表ではなく生のペイロードから読み取ってください。
5つのセクションを持つトークンは、暗号化されたJWEとして受け付けません。この判定はヘッダーを読まず、セクションの数だけで行っています。実際には正しく判定できますが、簡略化した方法だと知っておく価値があります。3つのセクションでないものはすべて受け付けず、ペイロードがオブジェクトではなくJSONの配列や単なる文字列にデコードされるものも同様です。警告を出すのは、アルゴリズムが「none」の場合と、署名鍵が公開鍵ではなく共有の秘密鍵であるHS系の場合です。RS、ES、PSで署名されたトークンには何も表示されません。つまり、このページで何も表示されないのは、既知の危険な形が見当たらないというだけで、お墨付きではありません。
ほかの目的には
ここでは何も保存されません。このページが存在してよい理由はそれだけですが、それでも習慣にすべきことではありません。プライバシーに関する主張は、読むだけでは確かめられません。ページを読み込んだ後にネットワークを切断し、デコーダーが動き続けるのを確認してください。背後にサーバーがあるツールにはそれができません。確認できない場所に貼り付けたトークンがまだ有効なら、あれこれ考えるより、ローテーションしてください。 ローテーションは1分の作業です。そうしなければ、まだ扉を開けられる認証情報について、自問自答が長く続くことになります。タブではなくパソコン上でトークンを読むなら、ペイロードはシェル1行で読めます。ドットで区切られた2番目のフィールドを切り出し、base64 -dでデコードして、jqに渡すだけです。
知りたいのがトークンの中身ではなく本物かどうかなら、このページは構造上、適したツールではありません。ほかのどのオンラインデコーダーも同じです。検証は、すでに鍵がある場所、つまりサーバー上の、お使いの言語のJWTライブラリで、発行者が公開しているJWKSに照らして行うべきものです。数行で済み、意味のある答えはそれだけです。代わりに検証すると申し出るサイトは、Webサイトに決して渡してはいけないただ1つの秘密を求めているのです。
よくある質問
トークンはどこかに送信されますか？
いいえ。このページにとって、それは機能の1つではなく、存在意義そのものです。JWTは通常、有効な認証情報です。持っている人は、期限が切れるまであなたとして操作できます。それをサーバーに送信するオンラインデコーダーに貼り付けることは、使える鍵を渡すことであり、ログを取らないという約束では取り消せません。このデコーダーは、今見ているページ内のただのJavaScriptです。何も保存されず、ログも残らず、通信も行われません。ページを読み込んだ後にWi-Fiをオフにしても、まったく同じように動作します。私たちの言葉をうのみにせず、プライバシーに関する主張を自分で確かめる最も簡単な方法です。
署名は検証されますか？
いいえ。署名鍵なしで誠実に検証できるオンラインデコーダーはありません。デコードと検証はまったく別の操作です。デコードはトークンのBase64を元に戻すだけで、誰でもどのトークンに対しても行え、トークンが本物かどうかについては何も証明しません。検証とは、署名に使われた秘密鍵または公開鍵で署名を計算し直すことで、その鍵は決してWebサイトに貼り付けてはいけません。ここに表示されるのはトークンが「主張している」内容です。その主張が信頼できるかどうかは、鍵を持つあなたのサーバーだけが答えられる問題です。
送ったJWTは相手に読まれますか？
はい、すべて読めます。これは多くの人が見落とす点です。JWTは署名されているだけで、暗号化されてはいません。ヘッダーとペイロードはBase64で、秘密を含まないエンコード方式にすぎないため、トークンを傍受した人は中のクレームをすべて読めます。署名はトークンを「書き換える」ことを防ぎますが、「読む」ことは何も防ぎません。JWTのペイロードに機密情報を入れないでください。パスワードもカード番号も、はがきに書けないような個人情報も入れてはいけません。
「none」アルゴリズムの警告は何を意味しますか？
トークンが自分は署名されていないと言っているということで、このページが報告する中でも最も深刻な指摘の1つです。`alg: none` は広く知られた認証回避の手口です。攻撃者は本物のトークンを手に入れ、ペイロードを自分が管理者だという内容に書き換え、アルゴリズムを「none」にして署名を取り除きます。ヘッダーを信用するライブラリはそれを受け入れてしまいます。主要なJWTライブラリは今ではどれもデフォルトでこれを防ぎますが、`alg` を信用する実装はまだ存在します。`alg: none` で届いたトークンは、そうでないと証明されるまで攻撃として扱ってください。
有効期限はどう読めばよいですか？
自動で読み取ります。`exp`、`iat`、`nbf` はUnixタイムスタンプ（1970年からの秒数）で、数値のままでは読めません。それぞれをお使いのタイムゾーンでの実際の日時として表示し、どれくらい前か、あとどれくらいかも示します。期限切れのトークンは、自分で計算させることなくはっきりそう表示します。`exp` がまったくないトークンも指摘します。期限のないJWTは期限切れによって無効化できず、署名鍵が有効な限り有効なままだからです。
トークンが3つではなく5つの部分に分かれています
それはJWEです。署名されているだけでなく暗号化されており、復号鍵がなければ中身は本当に読めません。ページはその形を認識し、意味のないものを表示する代わりにそう伝えます。5つの部分があるということは、ペイロードが本物の暗号文だということで、デコードできるものはありません。
標準のクレームにはどんなものがありますか？
登録済みのクレームは次のとおりです。`iss` は発行者、`sub` はトークンの対象（通常はユーザーID）、`aud` はトークンの宛先、`exp` は有効期限、`nbf` は有効開始日時、`iat` は発行日時、`jti` はトークンの一意のIDです。それ以外は、システムを作った人が独自に定めたものです。出力では登録済みのクレームそれぞれに意味のラベルが付くので、どの3文字の略語が何かを覚えておく必要はありません。
ご注意： ここで行うのはデコードで、検証ではありません。JWTの署名はトークンが改ざんされていないことを証明するもので、その確認には発行者の秘密鍵または公開鍵が必要です。それは決してWebページに貼り付けてはいけません。ここに表示されるものはすべて、証明されたものではなく主張されている内容として扱い、検証はサーバーで行ってください。
このツールをあなたのサイトに設置
ブログ、授業のページ、ヘルプ記事などに無料で設置できます。コードを1つ貼り付けるだけで、訪問者がそのページ上でツールを使えるようになります。