OpenAI: Workload Identity FederationがOIDCトークン交換により長期APIキーを廃止

OpenAIがWorkload Identity Federationを発表した——アプリケーションのコードや設定ファイルに長期APIキーを保存する必要を排除するセキュリティメカニズムだ。

アイデンティティトークン交換はどのように機能するか？

Workload Identity Federationは4つのコンポーネントに依存する。まず、OIDCエンドポイント、オーディエンス、キー検証ソースを持つ信頼できる外部発行者を記述するWorkload Identity Providerを定義する。次にサービスアカウントマッピングが外部トークンの特定の属性を特定のOpenAIサービスアカウントのトークン作成に認可する。3番目のステップでトークン交換がワークロードの外部トークンを受け取り、短期のOpenAIアクセストークンを返す。最後に、アプリケーションがそのトークンをAPIコールのベアラー認証情報として使用する。

システムはOIDC互換のJWTトークンを使用する。トークンの属性は、トークンクレームからカスタムマッチング基準を導出するための**Common Expression Language（CEL）**を通じて変換できる。

どのプラットフォームとクラウドがサポートされているか？

OpenAIは6つのプラットフォームに対して専用の統合ガイドを提供している：Kubernetes（プロジェクテッドサービスアカウントトークン）、AWS（STSまたはEKSプロジェクテッドトークン）、Microsoft Azure（マネージドアイデンティティまたはAKSトークン）、Google Cloud（メタデータサーバーまたはGKEトークン）、GitHub Actions（OIDCワークフロー）、SPIFFE（インフラストラクチャ向けJWT-SVID標準）。

設定はOrganization Settings > Security > Workload Identity Providerを通じて行われ、組織オーナーが利用できる。JWKS検証はOIDCディスカバリと手動アップロードされたキーセットの両方をサポートする。ディスカバリドキュメントは600秒ごとに更新される。

これがAPIアクセスセキュリティにとって重要な理由は何か？

長期APIキーは永続的なセキュリティリスクを表す——一度侵害されると、手動で失効させるまで無制限のアクセスを可能にする。短期OIDCトークンは自動的に期限切れになり、特定のワークロードアイデンティティに結びついているため、攻撃対象面が大幅に削減される。

OpenAIはいくつかの実践を推奨している：ワークロードごとに個別のサービスアカウントを使用すること、開発環境と本番環境を分離すること、（ワイルドカードのみでなく）クレームを正確にマッチングすること、未使用のマッピングを定期的に監査すること。マッピングはワイルドカードマッチングをサポートするが、末尾のワイルドカードは1つのみ使用可能だ。

この標準の導入により、OpenAIはAWS、Google Cloud、Azureが本番ワークロードにすでに要求しているセキュリティプラクティスと整合する——トークン交換（token exchange）はOAuth 2.0 Token Exchange仕様（RFC 8693）に基づいている。