JWT デコーダー

JSON Web Token は意味のない文字列に見えますが、大部分は読めます。3 つの部分のうち 2 つは base64 で包んだ JSON にすぎません。このデコーダーはそれを開き、そのトークンが誰のためのもので、何を主張し、いつ失効するのかを示します。たいていはリクエストが弾かれる理由を探している最中に見るものです。秘密鍵があれば HMAC 署名まで検証できるので、そのトークンが本当に思っているシステムから出たものか分かります。トークンは生きた資格情報なので、ページ内で動くことが大事です。トークンも秘密鍵もどこにも送信されません。

JWT を読み解く手順

  1. トークンを貼り付けます。ドットで区切られた 3 つの部分すべてを、ヘッダーやクッキーにある形のまま入れてください。
  2. ヘッダーとペイロードを並べて読みます。ヘッダーには署名アルゴリズム、ペイロードにはクレームが入っています。
  3. 時刻の欄を見ます。exp・iat・nbf が実際の時刻として出て、失効したトークンには印が付きます。
  4. 署名を確かめるには、署名に使われた秘密鍵を貼り付けて検証を押します。HS256・HS384・HS512 で動きます。

JSON Web Token についてよくある質問

本物のトークンを貼っても大丈夫ですか?

ほかの多くの場所より安全です。読み解きはブラウザ内で行われ、ネットワークには何も送りません。それでもトークンは資格情報そのものです。画面やクリップボードを見た人はそれを手にしたことになり、生きたセッショントークンなら失効まで有効なままです。

ペイロードは暗号化されていますか?

されていません。ここに驚く方が多くいます。ヘッダーとペイロードは base64 で包んであるだけで、トークンを持つ人は鍵なしで読めます。署名は中身が書き換えられるのを防ぐだけで、読まれるのを防ぎません。秘密にすべきものを JWT のペイロードに入れないでください。

なぜ HS256 系しか検証できないのですか?

そちらは共有の秘密鍵で署名するため、ここに貼り付けられるからです。RS256 や ES256 などは秘密鍵で署名し対になる公開鍵で検証しますが、その公開鍵はたいてい発行元の JWKS から取得する必要があります。それには通信が要り、この道具は通信をしません。

署名が一致しません。何が問題ですか?

多くは署名に使った鍵ではないか、貼り付けの際に余分な空白や改行が混じった場合です。ヘッダーが名乗るのと違うアルゴリズムで署名されていたり、誰かが手を加えていたりすることもあります。後者こそ署名の検証がある理由です。

exp・iat・nbf は何を意味しますか?

いずれも秒単位の Unix 時刻で書かれる標準の時刻クレームです。exp はトークンが有効でなくなる時、iat は発行された時、nbf はこのトークンを使える最も早い時です。このページは 3 つとも普通の日付で示し、exp を過ぎたトークンには印を付けます。

Other tools

Languages