JWT デコーダー

JSON Web Tokenは、ドットで区切られた3つのBase64Urlエンコード済みセグメントで構成されます。署名アルゴリズムを示すヘッダー、クレームを含むペイロード、そして署名です。ヘッダーとペイロードはエンコードされているだけで暗号化はされていないため、トークンを持っている人なら誰でも中身を読むことができます。このツールは両方を瞬時にデコードします。形式はRFC 7519で定義されています。

トークンを貼り付けると何がわかる?

トークンを貼り付けると、ヘッダーとペイロードが整形されたJSONとして表示され、時刻に関するクレームがあれば併せて平易な言葉で説明されます。ヘッダーには通常、署名アルゴリズム(alg)とトークンの種類が記載されています。ペイロードには発行者側が設定した任意のクレームが入っていて、発行者(iss)、主体(sub)、対象者(aud)、有効期限(exp)、発行日時(iat)、有効開始時刻(nbf)といった標準的なものに加え、ロールやスコープなどプロバイダー独自のクレームが含まれることもあります。exp・iat・nbfについてはUnixタイムスタンプを読みやすい日時に変換し、トークンが期限切れかどうか、まだ有効になっていないかどうかも表示します。APIがトークンを拒否した理由を突き止めるには、たいていこれが一番早い方法です。デコードには、ドットで区切られたちょうど3つの部分と、最初の2つが有効なBase64UrlエンコードのJSONであることが必要です。それ以外の形式は不正なJWTとして報告されます。

トークンはどこかに送信される?

されません。デコード処理はすべてブラウザ内で完結し、トークンの分解とパースはローカルで行われるので、ネットワーク越しに何かが送信されることはありません。そのため、本番環境の実際のアクセストークンを貼り付けても、第三者を経由する心配なく安全に使えます。

このツールは署名の検証もする?

しません。これは重要な点です。このツールが行うのはヘッダーとペイロードのデコードだけで、実質的にはBase64Urlのデコードとそれに続くJSONのパースにすぎません。署名は一切チェックしないため、そのトークンが本物かどうか、改ざんされていないかどうかは判定できません。デコードはトークンが「何を主張しているか」を見せるだけであり、その主張が信頼できることを証明するのは検証の役目です。検証には発行者の署名鍵が必要で、通常はその鍵にアクセスできるサーバーやバックエンドのライブラリ側で行います。拒否されたトークンをデバッグする際、このツールでデコードしてクレームの中身が正しそうか確認するのは手早い方法ですが、デコードが成功したからといって署名が正しいとは限りません。

3つのセグメントがどう組み合わさっているか、標準クレームがそれぞれ何を意味するかについては、RFCと併せてAuth0のJWT解説も参考になります。