OpenAIのWorkload Identity Federation、APIキーをサーバーから短命トークンへ移す
OpenAI DevelopersのWorkload Identity Federationで重要なのは、APIキーの置き場所が変わることです。GitHub Actions、AWS、Kubernetes、Azure、Google Cloud、SPIFFEのような外部実行環境が、自分のIDトークンをOpenAIへ渡し、短命のOpenAIアクセストークンに交換する。これにより、CIやサーバーに長期APIキーを保存する運用から、どの実行環境、リポジトリ、ブランチ、サービスアカウントに発行を許すかを明示する運用へ移れます。
APIキーを置く場所から、発行してよい身元を決める設計へ
OpenAIの説明では、Workload Identity Federationは外部で発行されたIDトークンを、短命のOpenAIアクセストークンへ交換する仕組みです。構成要素は、信頼するOIDC issuerを表すWorkload Identity Provider、外部トークンの属性をOpenAI service accountへ結びつけるmapping、token exchange request、そしてOpenAI APIへ送るBearer tokenです。
ここで変わるのは、認証情報をどこへ保存するかです。従来の長期APIキーは、CIのSecrets、サーバーの環境変数、秘密管理サービスに置かれがちでした。Workload Identity Federationでは、実行環境がその場でIDトークンを発行し、OpenAI側がissuer、audience、署名、属性を確認してから短命トークンを返します。
Interface Wire的に見るべき点は、これは管理者向けの地味な認証機能でありながら、AIエージェントや自動処理の安全な入口を作るUIでもあることです。誰がキーを持っているかではなく、どのワークロードなら一時的にOpenAI APIへ入ってよいかを、管理画面のproviderとmappingで表す形になります。
GitHub ActionsではSecretsではなくOIDCトークンから始まる
GitHub Actions向けガイドは、この変化をかなり具体的に見せています。workflow jobに`id-token: write`を与えると、GitHubはそのjob用のOIDC JWTを発行できます。OpenAIはissuer、audience、signature、mapping attributesを検証し、条件に合う場合だけOpenAIアクセストークンを返します。
GitHub tokenには、repository、repository_owner、ref、workflow、workflow_ref、environment、run_idなどのclaimが含まれます。OpenAI側のmappingでは、たとえば特定のrepositoryや`refs/heads/main`だけを通すようにできます。これは『このリポジトリのこのブランチのデプロイだけがOpenAI APIを呼べる』という境界を作るための部品です。
AIを使うCIが増えるほど、この違いは大きくなります。長期APIキーをSecretsに置く方式では、漏えい時の影響範囲が広くなりやすい。OIDC交換では、実行ごとの身元と短命トークンに寄せられるため、キーの配布ではなく発行条件の設計が中心になります。
AWSやKubernetesでも短命トークンとマッピングが境界になる
AWS向けガイドでは、AWS STSが発行するOIDC JWTやAmazon EKSのprojected service account tokenをOpenAIアクセストークンへ交換する流れが示されています。OpenAIは、SigV4署名リクエストやAWS STSの一時アクセスキーをsubject tokenとしては扱わず、OIDC JWTを検証対象にします。
AWSの例では、audienceを`https://api.openai.com/v1`に絞り、最大token lifetimeを300秒にするIAM conditionも示されています。これは、クラウド側でも『OpenAI向けに短く発行されたIDトークン』だけを渡す設計です。さらにOpenAI側では、service account mappingのpermissionsで、mintされるtokenの権限をservice accountより広げずに絞れます。
つまりWorkload Identity Federationは、単なるAPIキー代替ではありません。クラウド、CI、Kubernetes、SPIFFEの身元をOpenAI service accountへ翻訳し、その翻訳をissuer、audience、claim、key rotation、mapping permissionで管理する仕組みです。AIを本番ワークロードへ入れるなら、プロンプトやモデル選びだけでなく、この認証境界が運用UIの一部になります。
OpenAI APIを本番で使うとき、これまでは『APIキーをどこに安全に置くか』が最初の設計問題になりがちでした。Workload Identity Federationは、その問いを『どの外部ワークロードなら、どの条件で、どのservice accountの短命トークンをmintしてよいか』へ置き換えます。AIエージェントやCIが自動で動くほど、長期キーの保管より、発行条件と監査できる身元のほうが重要になります。