OAuth 2.0 Token Introspection (RFC 7662) とローカルJWT検証の比較

OAuth2 Security Backend Architecture
結論

即時失効が必要な高リスク処理には Introspection、高トラフィック処理には ローカルJWT検証 です。

# RFC 7662 公式仕様：Token Introspection リクエストとアクティブ応答
POST /introspect HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW

token=mF_9.B5f-4.1JqM&token_type_hint=access_token

# 認可サーバーからのリアルタイム応答
HTTP/1.1 200 OK
Content-Type: application/json

{
  "active": true,
  "scope": "read write",
  "client_id": "s6BhdRkqt3",
  "sub": "248289761001",
  "exp": 1690000000
}

RFC 7662公式仕様：2つのトークン検証アプローチ比較

評価軸Token Introspection (RFC 7662)ローカル JWT 署名検証
失効検知 (Revocation)◯ 認可サーバーへ直接確認し「即時検知」❌ exp (有効期限) が切れるまで検知不可
APIパフォーマンス❌ 毎回認可サーバーへのネットワークHTTP通信が発生◯ メモリ内検証で超高速 (0ms)
認可サーバーの負荷❌ トラフィック増大に伴い認可サーバーがボトルネック化◯ 極小 (初回JWKS取得のみ)
トークン形式不透明 (Opaque) トークンでも使用可能構造化された JWT (JSON) が必須

実際に起こる障害：ローカルJWT検証による「アクセス剥奪タイムラグ」事故

セキュリティ運用で最も問題となるのが、ローカル JWT 検証のみで構成されたWebシステムです。

管理者ユーザーが対象のアカウントを「凍結」または「権限剥奪」したり、パスワード変更による「全端末ログアウト」を実行しても、ローカル検証を行っている各APIサーバーは JWT 内の exp（有効期限：例 あと2時間）が切れるまで権限剥奪を検知できず、攻撃者に不正アクセスを許し続ける障害 が発生します。

ハイブリッド設計手順

  1. 管理者操作、決済、パスワード変更、個人情報書き換えなどの高リスクエンドポイントでは Token Introspection (RFC 7662) を実行し、active: true であることを同調確認する
  2. タイムラグが数分間許容される一般的なデータ参照・閲覧系エンドポイントでは ローカル JWT 署名検証 を適用し、インフラ負荷を下げて応答速度を高める
  3. ローカル検証を使用する場合は、アクセストークンの有効期限（exp）を 5分〜15分 などの短い時間に設定し、リフレッシュトークン運用と組み合わせる