この記事のポイント
- 架空JWTからsub・role・iatを読める形にできた
- デコードは内容表示であり署名の正当性確認とは別だ
- ログイン不要で使えたが実サービスのトークンは貼らない方がよい
サムネイルはイメージ写真。写真の配布元：Unsplash（利用許諾）。本文の画面は実際の操作時に撮影した。
検証環境：2026年10月10日、Windows上のGoogle Chrome。jwt.io日本語版を無料・未ログインで利用し、筆者が作った架空データだけを入力した。
Webサービスのログイン周辺で見かける、ピリオドで3区画に分かれた長い文字列がJWTである。今回はsubをryxeon-demo、roleをreaderにした架空トークンをjwt.ioへ貼った。
画面右側にはヘッダーのalg: noneとtyp: JWT、ペイロードのsub、role、iatがJSONとして表示された。JWTは暗号文とは限らず、ペイロードはBase64URLを元へ戻すだけで読める。ここが「デコード」と「秘密を解読する」の違いである。
操作手順
- jwt.ioのJWTデバッガーを開く。
- 左側の「JSON Web Token (JWT)」欄を一度クリアする。
- 検証用の架空JWTを貼り付ける。
- 右側の「デコードされたヘッダー」と「デコードされたペイロード」を読む。
この画面で文字が読めても、本物の発行元が署名した正当なトークンとは限らない。署名アルゴリズム、鍵、発行者、期限などの検証は別の工程である。今回の
alg: noneは署名なしの学習用データだ。「見える情報」と「信用できる情報」を分ける
subは対象となる利用者など、iatは発行時刻を表す登録済みクレームである。一方、roleのような独自クレームも入れられる。項目名を見れば用途を推測できるが、値を信用するには署名検証とサービス側のルール確認が必要だ。
実サービスのアクセストークンやセッショントークンは、本人確認に使われる情報になり得る。操作を試すなら、今回のように架空の値を使うのが適切である。
コメント