製品プロフィール

JWT

トークン形式

「誰が・何ができるか」を署名付き JSON で運ぶトークン形式。OIDC の ID トークンや API 認証で広く使われる。詳しくは Web の認証も参照。

3つの要点
TL;DR
  1. 権限を署名付き JSON で運ぶトークン形式。
  2. ステートレスで API やマイクロサービス向き。
  3. 即時失効が要るならセッション認証を選ぶ。

基本情報

仕様と立ち位置

製品・技術の概要JWT「誰が・何ができるか」を署名付き JSON で運ぶトークン形式。OIDC の ID トークンや API 認証で広く使われる。詳しくは Web の認証も参照。
種別
トークン形式
目的
認証/認可情報の運搬
トークン/形式
署名付き JSON
最大の強み
ステートレスサーバ側に保存不要)署名で改ざん検知
代表的な用途
API 認証OIDC の ID トークン / サービス間のクレーム伝達

選定ガイド

選定ポイント

採用する理由と、事前に受け入れるべきトレードオフを分けて確認します。

採用に向く条件

選ぶ理由

  1. ステートレス(サーバ側に保存不要)
  2. 署名で改ざん検知
  3. API/マイクロサービスと相性が良い

事前に確認する条件

考慮すべき点

  1. 発行後すぐ失効できない(要設計)
  2. ペイロードは暗号化されない(署名のみ)
  3. 保存場所で XSS/CSRF リスク

詳しい解説

もっと詳しく

どんな仕組みか

JWT(JSON Web Token)は、署名付きで自己完結したトークンです。中身に「誰か」「いつまで有効か」といった情報(クレーム)を持ち、それ全体に署名が付くことで、受け取った側が改ざんを検知できます。

「自己完結」が肝で、トークン自体に必要な情報が入っているため、サーバー側にセッションを保持しなくても検証できます。

横にスクロール

認可サーバーが短命のJWTアクセストークンを署名して発行し、API入口が信頼済み公開鍵、許可アルゴリズム、署名、用途、発行者、対象API、期限を検証してから資源と操作を認可し、期限更新と署名鍵を管理する流れ
JWTは署名だけでなく、用途、発行者、対象API、期限をAPI側の期待値と照合して初めて受理できます。検証後もscopeだけで許可せず、対象資源と操作の関係をAPIで判定します。短命化、更新資格情報のローテーション、署名鍵の重複期間まで含めて運用します。

どう動くのか(構造)

JWT は 3 つの部分を Base64URL でエンコードし、ドット区切りでつないだ文字列です。

header.payload.signature
- header:    署名アルゴリズム(alg)・型(typ)
- payload:   クレーム(sub 主体, exp 期限, iat 発行時刻, iss 発行者, aud 対象)
- signature: header と payload への署名

受け取った側は署名を検証し、改ざんされていないこと、exp が有効期限内であること、issaud が期待どおりかを確認します。サーバーに問い合わせず手元で検証できるため、ステートレスに扱えます。

署名方式には、共有秘密鍵の HMAC(HS256 など) と、公開鍵・秘密鍵の RSA/ECDSA(RS256・ES256 など) があります。発行者だけが秘密鍵を持ち、検証側は公開鍵で確認する後者は、鍵配布を伴う分散構成に向きます。

他の方式との違い

サーバー側にセッション情報を持つ伝統的な セッション方式 と対照的です。

観点JWT(トークン)セッション
状態の置き場所トークン自身が持つサーバーが保持
ストア不要(ステートレス)必要(Redis 等)
失効難しい(期限切れ待ちが基本)サーバー側で即時削除
スケールしやすい共有ストアが要る
向く構成複数サービス横断の API 認可単一 Web アプリのログイン

スケールしやすさと引き換えに、発行後の即時無効化が難しい、という性質を理解しておく必要があります。

使いどころ・注意点

複数のサーバーにまたがる API 認可や、サーバー間でセッションを共有したくない構成、OIDC の ID トークンとして広く使われます。

署名検証と機密情報の扱い

JWT は署名されるが暗号化はされないため、payload は誰でも読めます。機密情報は入れないこと。検証側は必ず署名を確認し、algnone にされる攻撃や、HMAC と RSA の取り違え攻撃を防ぐため、許可するアルゴリズムをサーバー側で固定します。有効期限は短めにし、更新はリフレッシュトークンで行い、失効が必要な用途では失効リスト(denylist)や短命化で補います。

総じて JWT は、ステートレスに検証できる自己完結トークンとして分散 API 認可に強い一方、即時失効の弱さと署名検証の落とし穴を理解して使うことが重要です。

実装・運用の視点

JWTを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

API 認証

比較で見る軸

種別: トークン形式 / 目的: 認証/認可情報の運搬 / トークン/形式: 署名付き JSON

導入後に効く点

署名で改ざん検知

先に潰すリスク

発行後すぐ失効できない(要設計)

数字・仕様の読み方
種別
トークン形式
目的
認証/認可情報の運搬
トークン/形式
署名付き JSON

判断チェックリスト

  • 自社の用途が「API 認証 / OIDC の ID トークン」に近いか確認する。
  • 強みである「ステートレス(サーバ側に保存不要)」が本当に評価軸になるか確認する。
  • 注意点の「発行後すぐ失効できない(要設計)」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

API 認証OIDC の ID トークンサービス間のクレーム伝達

向いている用途

こんな用途に向く

API 認証OIDC の ID トークンサービス間のクレーム伝達
公式サイト