認証エラーを調べるときに確認したい項目
APIから401が返ったときは、まず想定したトークンを送っているか確認します。issは発行者、subは主体、audは受信対象を表します。audには文字列だけでなく配列が入る場合もあります。
読めることと信頼できることは別です。署名が正しくないトークンでも、JSONが整っていれば内容は表示できます。どのクレームを必須にするかは、利用するプロトコルやアプリケーションの要件によって異なります。
ヘッダー・ペイロード・署名の読み方
一般的な署名付きJWTはheader.payload.signatureの3部構成です。先頭の2部分はBase64urlでエンコードしたUTF-8のJSONで、最後は署名またはMACのバイト列です。署名部分までJSONとして読めるわけではありません。
JWT単体、Bearer付き、またはAuthorization: Bearer付きの値を入力できます。HTTPリクエスト全体は貼り付けないでください。JSONは見やすく整形され、コピー時も大きな整数や指数表記の元の表現が保たれます。
expの数値を日時に直す
expは有効期限、nbfは使用開始日時、iatは発行日時です。単位はUnixエポックからの秒数で、JavaScriptのミリ秒とは異なります。1704067200は2024年1月1日0時00分UTCを表します。
比較には端末の時計を使い、時刻のずれを吸収する猶予は加えません。有効期限が先でも署名や受信対象が正しいとは限りません。iatが未来の場合も、表示だけで一律に無効とは判定しません。
デコードと署名検証を分けて考える
Base64urlは暗号化ではないため、内容を読むだけなら鍵は不要です。トークンを受け入れる側では信頼する鍵と許可するアルゴリズムを設定し、署名、発行者、受信対象、時刻などを検証します。入力されたalgだけを根拠に信頼設定を決めないでください。
このデコーダーは鍵のURLにアクセスせず、埋め込み鍵も使用しません。暗号化された5部構成のJWE、入れ子のJWT、b64: falseには対応していません。上限は50,000文字と64階層です。重複キーは解釈が曖昧になるためエラーにします。
サンプルで確認
よくある疑問
秘密鍵なしでJWTを読めますか？
通常の3部構成なら読めます。ヘッダーとペイロードはBase64urlを戻すだけです。秘密鍵や共有シークレット、公開鍵が関係するのは暗号学的な検証で、このツールでは行いません。
署名が空でも表示されるのはなぜですか？
alg: noneは署名のない非保護JWTを示します。第3部分が空でも末尾のドットは必要です。表示できても認証に利用してよいという意味ではありません。
入力は保存されますか？
ツールによる保存やデコード用APIへの送信は行いません。URLにも追加しません。実際のBearerトークンはアクセス権を持つ可能性があるため、動作確認には架空のサンプルを利用できます。
サンプルは認証に使えますか？
使えません。期限切れの例は2024年1月1日1時00分UTCがexpで、署名は仮の値です。Unicodeの例も仮の署名を使います。署名なしの例はalg: noneで、いずれも説明用です。
JWTを貼ってもエラーになります
3つの部分が揃っているか、途中に空白や引用符、パディングがないか確認してください。JSONオブジェクト以外の値、壊れたUTF-8、重複キーも受け付けません。5部構成ならJWEの可能性があります。