構造#

JWT は3つのパートをドットで繋いだ文字列です。

1
<ヘッダー>.<ペイロード>.<署名>

• ヘッダー：アルゴリズム（例：HS256、RS256）とトークン種別。
• ペイロード：実際に運びたい情報（ユーザーID、ロール、有効期限など）。これを「クレーム」と呼びます。
• 署名：ヘッダーとペイロードを秘密鍵（または公開鍵ペア）で署名したもの。

3つのパートは Base64URL でエンコードされているだけで、暗号化されているわけではない 点に注意が必要です。誰でも中身を読めます。

何が便利か#

• サーバーがセッション情報を保持しなくていいので、複数台にスケールしやすい。
• マイクロサービス間でユーザー情報を持ち回すときの共通フォーマットとして使いやすい。
• 公開鍵方式（RS256など）にすれば、検証だけ別サービスに任せる構成が取れる。

実運用での注意点#

• 失効が苦手：一度発行すると、有効期限まで生き続けます。ログアウトや「全端末から強制サインアウト」を実現するには、別途ブラックリストやバージョン番号の仕組みが必要です。
• 短い有効期限＋リフレッシュトークン が定番の組み合わせ。
• 秘密情報を入れない：ペイロードは読めるので、機微な情報は載せません。
• alg: none 攻撃：受け取った JWT のヘッダーで指定されたアルゴリズムをそのまま信じると、署名なしのトークンを受け入れてしまう実装ミスにつながります。サーバー側で許容するアルゴリズムを固定するのが鉄則です。
• 保存場所：LocalStorage に置くと XSS の的になりやすく、HttpOnly Cookie に置くと CSRF 対策が必要、というトレードオフがあります。

便利さの裏側に運用上の罠が並んでいるので、「セッションの代替」と単純に捉えず、性質の違うトークンだと意識して使うのが安全です。