JWTデコーダー

JWTはRFC 7519(2015年5月)で定義されており、英語の「jot」のように発音することが推奨されています。一般的な署名付きの形式は、ドットでつないだ3つのBase64url文字列(header.payload.signature)です。ヘッダーにはalgで署名アルゴリズム(HS256やRS256など)が、kidで鍵IDが指定されていることもあります。ペイロードにはクレームが入ります。クレームはJSONのフィールドで、sub(ユーザー)、iss(発行者)、aud(想定される受信者)、そして1970年1月1日 UTCからの秒数で表されるexp、nbf、iatなどがあります。このデコーダーはこれらをローカル時刻とISO 8601に変換し、トークンが期限切れか、まだ有効でないか、有効期間内かを表示します。

Base64urlはエンコードであって暗号化ではないため、トークンを持っている人なら誰でも、このページと同じようにペイロードを読めます。パスワードやカード番号などの秘密情報は、クレームに入れないでください。ドットで区切られた5つの部分からなるトークンはJWE(暗号化トークン)で、鍵がなければ内容を読めません。その場合はデコーダーがその旨を表示します。Authorizationヘッダーからコピーした先頭の「Bearer 」は自動的に取り除かれます。

署名は、ヘッダーとペイロードが鍵の保持者によって作られ、その後に改ざんされていないことを証明するものです。検証にはその鍵が必要で、HS256などのHMAC系アルゴリズムでは共有シークレット、RS256、ES256、EdDSAでは発行者の公開鍵を使います。本番の署名シークレットをWebページに貼り付けるのは避けるべきですし、鍵なしでトークンを保証するかのように見せるデコーダーは誤った安心感を与えます。そのため、このツールは署名を表示しますが検証はしません。表示される内容は事実ではなく、トークンが主張している内容として扱ってください。

検証はサーバー側で、メンテナンスされているライブラリを使い、想定するアルゴリズムを固定して行うべきです。過去の代表的な2つの失敗がその理由です。1つはalg「none」を受け入れてしまい、誰でも署名なしのトークンを偽造できる問題。もう1つはアルゴリズム混同で、RS256を想定しているサーバーが、公開鍵をHMACのシークレットとして使うHS256署名を検証させられてしまう問題です。デコーダーはデバッグ用です。プロバイダーがどんなクレームを発行しているかの確認、audの間違いの発見、exp が1分前に過ぎたせいでセッションが失敗したと突き止める、といった用途に向いています。Base64urlの各セグメントをそのまま読みたい場合は、Base64デコーダーをご利用ください。