JWTデコード

デコードは完全にブラウザ内で行われ、トークンが送信されることはありません。DevToolsを開き、Networkパネルに切り替えてトークンを貼り付けてみてください。それを運ぶリクエストは何も表示されないはずです。このページは、サーバーに送信するタイプのデコーダーよりも明確に安全です。そのようなサーバーでは、トークンがアクセスログに残ってしまいます。残る注意点はこのサイトの話ではありません。管理下にないマシンのブラウザに貼り付けたクレデンシャルは、後でローテーションすべきというものです。

検証には鍵が必要だからです。HS256なら共有シークレット、RS256なら発行者の公開鍵で、通常はJWKSエンドポイントから取得します。ブラウザのページがそのどちらかを行うには、トークンかシークレットをどこかに送るしかなく、それではこのページを安全に使える性質が壊れてしまいます。検証は、鍵がすでにあるあなたのサービスの中で行うべきものです。

デコードできることと受け入れられることは、別の問題です。最も多い原因は次のとおりです。トークンの有効期限が切れている（expの行を確認してください——このツールは実在の日付で表示します）。オーディエンスがサービスの期待と一致していない。発行サーバーの時計が進んでいて、nbfが未来になっている。あるいは、サービスに設定された鍵に対して署名が検証できない。多くの場合これは、発行者が鍵をローテーションし、kidがキャッシュがまだ取り込んでいない鍵を指しているせいです。

トークンが未署名だという意味です。危険なのは値そのものではなく、検証器がそれをどう扱うかです。歴史的に、一部のJWTライブラリはトークンからalgを読み、それに応じて検証方式を選んでいました。そのため攻撃者は、有効なトークンを取り、アルゴリズムをnoneに変え、署名を剥がして、受け入れさせることができました。正しい検証器は、期待するアルゴリズムを自分自身の設定から決め、トークンの主張を無視します。

いいえ。標準のJWT（JWS）は署名であって、暗号化ではありません——署名はペイロードが改ざんされていないことを証明するだけで、内容を隠す働きはありません。すべてのクレームは、トークンを手にした人なら読めます。それをまさにこのページが実演しています。内容を隠す必要があるなら、必要なのはJWEです。JWEはセグメントが3つではなく5つで、復号鍵なしでは読めません。

はい。有効期限はペイロード内のクレームであって、エンコードの性質ではないので、期限切れのトークンも有効なトークンとまったく同じようにデコードできます。このツールはそれを読み、いつ期限切れになったか、どれほど前に切れたかを教えてくれます。断続的な401が権限の問題ではなくトークンの寿命の問題だと確認する最短の方法になることが、たいていです。