JWTデコーダー

JSON Web Tokenは一見すると解読不能な文字の羅列に見えますが、実際にはドットで区切られた3つのBase64URLエンコード部分——ヘッダー、ペイロード、署名——にすぎません。ヘッダーとペイロードのデコードはそもそも暗号化ではなく、トークンさえあれば誰でも中のクレームを読めてしまいます。だからこそ、機密情報をJWTのペイロードに詰め込んではいけないのです。ただし現実には、確認したいトークンが使い捨てのテストデータであることはまれです。多くの場合、それは本番アプリの現役セッショントークンであったり、APIアクセストークンであったり、デバッグ中にブラウザの開発者ツールから直接取り出したログインCookieだったりします——つまり、悪用されれば実際にアクセス権を与えてしまう本物の認証情報です。それをよく知らないウェブサイトに貼り付けることは、自分のセッションを見ず知らずのサーバーに渡すことにほかなりません。

このツールはそうしたことを一切行いません。トークンを貼り付けた瞬間、ヘッダーとペイロードはブラウザ内で動作する素のJavaScriptによってデコードされます——ドットで分割し、Base64URLデコードし、JSONとしてパースするだけで、どのデータもどこにも送信されません。署名の検証も同様で、現代のブラウザに標準搭載されているWeb Crypto API（`SubtleCrypto`）を利用します。HMAC系アルゴリズム（HS256、HS384、HS512）は入力されたシークレットで検証され、RSA系アルゴリズム（RS256、RS384、RS512）は貼り付けられたPEM形式の公開鍵で検証されます。暗号用のシークレットも検証処理そのものも、そのタブの中だけで完結します。ページを再読み込みすれば、トークンもシークレットも鍵も、すべて跡形もなく消えます。

トークンを貼り付けると、ヘッダーとペイロードが整形されて表示されるほか、標準的な`exp`、`iat`、`nbf`クレームを人が読める日時形式に変換した内容も確認できます。トークンの`exp`がすでに過ぎている場合は、はっきりと「期限切れ」のバッジが表示されるので、「ログアウトさせられた」というバグ報告が実は単なる期限切れだったのかどうかをすぐに確認できます。アルゴリズムがHS256/384/512またはRS256/384/512であれば、対応するシークレットまたは公開鍵を入力することで、署名が本物か改ざんされていないかをチェックできます。それ以外のアルゴリズム（ES256や署名なしの`none`など）もデコード自体は問題なく行えますが、結果を偽って表示するくらいなら検証機能自体を提供しない方針にしています。ローカル開発向けには、編集可能なヘッダー／ペイロード欄でクレームを書き換え——例えばユーザーIDやロールを変更し——テストサーバーと同じHS256のシークレットでトークンを再署名できます。これは、完全なログインフローを立ち上げることなく認可ロジックをテストする際によく使われる方法です。

JWTのペイロードはデコードすればただの読みやすいJSONになるため、より深くネストされたクレームを詳しく調べたい場合は、JSON Formatter & Validatorツールと組み合わせるのが自然です。繰り返しになりますが重要なセキュリティ上の注意点として、デコードにはシークレットが一切不要である以上、確認が終わったトークンはその瞬間から機密情報として扱ってください。もし本来は短命であるべき認証情報が、ここに貼り付けられる前にどこか別の場所にも残っている可能性があるなら、念のため失効・再発行することをおすすめします。