JWTのiss(発行者)クレーム
JWT iss(発行者)クレームの仕組み、トークン作成者の識別方法、発行者検証がトークン悪用を防ぐ理由、複数プロバイダー構成について解説します。
詳細な説明
iss(発行者)クレームは、JWTを作成し署名したエンティティを識別します。大文字・小文字を区別する文字列で、通常は認可サーバーを指すURLです。issクレームの検証は、トークンが攻撃者によって偽造されたものや信頼できないサービスによって生成されたものではなく、信頼できる機関によって発行されたことを保証する基本的なセキュリティチェックです。
形式と慣例:
{
"iss": "https://auth.example.com",
"sub": "user123",
"aud": "api.example.com",
"exp": 1700003600
}
OpenID Connect仕様では、issはHTTPS URLであることが求められます。OAuth 2.0 Authorization Server Metadata(RFC 8414)では、issの値を使用して{iss}/.well-known/openid-configurationにあるサーバーのディスカバリドキュメントを特定します。これにより、クライアントは署名鍵、トークンエンドポイント、サポートされるアルゴリズムを動的に発見できます。
発行者検証が重要な理由:
発行者検証がなければ、攻撃者は一つのサービスの有効なトークンを取得し、別のサービスに対してリプレイすることができます。例えば、サービスAとサービスBの両方がJWTを受け入れるがissをチェックしない場合、サービスAの有効なトークンを持つ攻撃者がサービスBにアクセスできてしまいます。issが期待される認可サーバーと一致することを確認することで、各サービスは他のシステム向けのトークンを拒否します。
マルチプロバイダーアーキテクチャ:
現代のアプリケーションは、従業員向けの企業IDプロバイダー、顧客向けのソーシャルログインプロバイダー、内部サービス向けのマシン間トークンサービスなど、複数の発行者からのトークンを受け入れることがよくあります。サーバーは信頼された発行者のリストを管理し、それぞれに独自の署名鍵セットを持ちます。トークンが到着すると、サーバーはissを読み取り、対応する鍵セットを検索して署名を検証します。issが信頼リストにない場合、トークンは即座に拒否されます。
実装のベストプラクティス:
信頼された発行者の明示的な許可リストに対してissを常に検証してください。任意の発行者からのトークンを受け入れないでください。部分文字列マッチングではなく、完全な文字列比較を使用して、https://auth.example.com.evil.comのような攻撃を防いでください。JWKSベースの設定では、各発行者を固有のJWKSエンドポイントにマッピングし、鍵を適切にキャッシュしてください。
ユースケース
マイクロサービスプラットフォームが、承認された認証サーバーからのトークンのみがアクセスを許可されるように、issクレームを信頼済みIDプロバイダーのリストに対して検証します。