JWTデコーダー

ドットでつながった3つのテキスト

ウェブサイトにログインしたあと、サーバーは次のリクエストでもあなたを見分ける必要があります。よく使われるのが、署名付きの短いメモをブラウザーに渡す方法です。「これはユーザー48213、注文の閲覧が可能、15時15分まで」といった内容です。このメモがJSON Web Token、略してJWTです。

JWTは長いランダムな文字列に見えますが、形はいつも同じ、header.payload.signature です。

• ヘッダーは小さなJSONオブジェクトで、署名のアルゴリズム（alg）と、多くの場合は使われた鍵（kid）を示します。
• ペイロードはクレームのJSONオブジェクトです。クレームとは、sub（誰か）、aud（どのサービス向けか）、exp（いつまでか）といった記述のことです。
• 署名は、最初の2つの部分と鍵から計算した封印です。

ヘッダーとペイロードはBase64URLで書かれています。これはバイト列を英字、数字、-、_ で表す方式で、アドレスやHTTPヘッダーを通っても壊れません。ほぼすべてのトークンが eyJ で始まるのもそのためで、{" をこの方式で表すとそうなります。

エンコードは暗号化ではありません

Base64URLは表記方法にすぎません。何も鍵をかけておらず、テキストに戻すのに鍵は要りません。このページがしているのはそれだけです。つまり、署名付きのJWTは何も隠していません。ペイロードにメールアドレス、ロール、内部IDが入っていれば、トークンを手にした誰でも読めます。ブラウザー拡張機能でも、プロキシのログでも、スクリーンショットでも同じです。

署名がもたらすのは完全性です。ペイロードを1文字でも変えると封印が合わなくなり、サーバーはトークンを拒否します。読むことはできても、書き換えることはできないのです。

このページが読み取るものと指摘するもの

デコーダーは先頭の Bearer、空白、改行を取り除き、トークンを分割して、ヘッダーとペイロードを整形したJSONで表示します。そのあとクレームを一つずつ確認します。3つの日時、exp、nbf（この時刻より前は無効）、iat（発行時刻）は、1970年1月1日からの秒数です。お使いのタイムゾーンとUTCで表示し、「あと12分有効」のような残り時間も示します。

アルゴリズムについての説明も表示します。HS256 は一つの共有シークレットで署名と検証の両方を行います。RS256、ES256、EdDSA は鍵ペアを使い、秘密鍵で署名し、公開鍵で検証します。そのため、検証だけを行うサービスはトークンを作れません。

デコードではわからないこと

このページは署名を検証しません。検証には発行者のシークレットか公開鍵が必要です。署名用のシークレットを求めてくるページは、閉じるべきページです。その結果、ここでは偽造トークンも本物も同じように見えます。表示内容は「トークンがこう主張している」と読み、「このトークンは有効だ」とは決して読まないでください。

同じ理由で、「期限切れでない」とは、exp がお使いの端末の時計より後だという意味でしかありません。サーバーは1時間前にトークンを失効させているかもしれません。

受け取る側を実装しているなら、肝心のチェックはあなたのコードで行われます。想定したアルゴリズムだけを受け入れ、すでに信頼している鍵で署名を検証し、そのあと iss、aud、exp を想定値と比べてください。保守されているライブラリを使い、トークンが要求する alg によって処理を分岐させてはいけません。

有効なトークンは認証情報です

期限が切れるまで、Bearerトークンは提示した人なら誰にでも使えます。本番のトークンをウェブサイトに貼り付ければ、そのサイトに渡したことになります。デコードがブラウザー内で行われる場合は別で、ここではそうなっています。トークンを運ぶリクエストはなく、アドレスバーにも書かれず、ブラウザーのストレージにも保存されません。私たちの言葉を信じる必要はありません。開発者ツールのネットワークタブを見るか、ページを読み込んでからオフラインにして貼り付けてみてください。

それでも一番安全なのは、テスト用アカウントのトークンか、期限切れのトークンでデバッグする習慣です。本物のトークンがチャット、チケット、公開ログに出てしまったら、すべての場所からログアウトするか、発行者に失効を依頼してください。