JSON Web Tokenを解説します。ヘッダー、ペイロード、署名、RFC 7519の7つの登録クレーム、セキュリティの落とし穴、そしてトークンをどこにも送信しないデコーダーを紹介します。
JWT（JSON Web Token）は、ドットで区切られた3つのbase64urlの部分からなる、コンパクトでURLセーフな文字列です：アルゴリズムを示すヘッダー、subやexpなどのクレームを含むペイロード、そして署名です。ペイロードは誰でもデコードして読めます。改ざんされていないことを証明できるのは、正しい鍵で検証された署名だけです。
登録済みクレーム名（RFC 7519、セクション4.1）
下のデコーダーにトークンを貼り付けると、ヘッダーとペイロードが表示され、各登録クレームの説明と、すべてのタイムスタンプを読みやすい日付に変換した結果が確認できます。デコードはこのページ自身のJavaScriptで行われるため、トークンがアップロードされることはありません。有効なトークンは誰かのアカウントへの鍵なので、これは重要です。
デコードがブラウザー内で行われる場合に限ります。トークンは認証情報です。有効なトークンを持つ人は誰でも、期限切れまでそのユーザーとしてAPIを呼び出せます。このページのデコーダーはローカルで動作し何も送信しませんが、最も安全な習慣は、テスト用トークンだけをデコードすることです。
通常の署名付きJWT（JWS）は暗号化されていません。ペイロードはbase64urlでエンコードされているだけで、誰でも元に戻せます。暗号化されたトークンはJWEとして存在し、ドット区切りの部分が3つではなく5つありますが、ほとんどのログイン用やAPI用のトークンは暗号化ではなく署名されたものです。
NumericDateです：1970-01-01T00:00:00Zからの経過秒数（整数）で、うるう秒は無視します。JavaScriptのDate.now()はミリ秒を返すため、比較の前に1000で割る必要があります。これは非常によくあるバグです。
localStorageはページ上で動くどのスクリプトからも読めるため、クロスサイトスクリプティングのバグが1つあればトークンを盗まれます。HttpOnly、Secure、SameSiteのcookieならスクリプトから遠ざけられますが、CSRF対策が必要になります。ブラウザーのセッションにはcookieを選ぶチームが多くあります。
トークンはexpまで有効なままなので、それ単体ではできません。短い有効期限と、取り消し可能なリフレッシュトークンを組み合わせるか、早期に無効化すべきトークンのjti値を拒否リストで管理しましょう。
クレームを検証せずに読み取ります。UIにユーザー名を表示するには十分ですが、アクセス可否の判断には絶対に使わないでください。
jwtVerifyは署名、exp、nbfを確認し、これらのオプションを付けると発行者、受信者、許可されたアルゴリズムも確認します。
トークンを貼り付けると、ヘッダーとペイロードを読めます。デコードはブラウザー内で行われ、トークンが送信、保存、記録されることはありません。
トークンを発行した者
トークンが対象とする者、通常はユーザーID
トークンを受け入れるべき受信者
この時刻以降は拒否する
この時刻より前は拒否する
トークンが作成された時刻
一意のID、再利用の防止に役立つ
JWT
サンプルトークンを読み込む
クリア
ヘッダー
ペイロード
署名（ここでは検証しません）
クレームの説明
クレーム
値
意味
カスタムクレーム
署名付きJWTはドットで区切られた3つの部分からなりますが、これは{n}つあります。
5つの部分は暗号化されたJWEを意味し、鍵がなければ読めません。
{n}番目の部分が有効なbase64urlのJSONではありません。
{v}に期限切れ
{v}まで有効
{v}から有効
algがnoneです：このトークンには署名がないため、拒否する必要があります。
ローカルでデコードしています。何もこのページの外に出ません。
無料で始める · クレジットカード不要