OpenAI API、mTLSとX.509ワークロードID連携をGA APIキー不要の認証へ
OpenAI API 公式ドキュメント公式発表
OpenAIAPIセキュリティ認証リリース
OpenAIは8月29日、APIの相互TLS(mTLS)とX.509ワークロードIDフェデレーションを正式提供にした。TLSクライアント証明書の身元を短命なアクセストークンに交換でき、APIキーの代替として使える。証明書とIDプロバイダーはPlatformコンソールから設定し、組織の既存のロールと権限で制御される。
何が発表されたか
OpenAI は 2026年8月29日、API チェンジログで相互TLS(mTLS)と X.509 ワークロードIDフェデレーションの一般提供(GA)を告知した。証明書と X.509 IDプロバイダーは Platform コンソールから直接設定でき、アクセスは組織に既に存在するロールと権限の仕組みで制御される。
公式ガイドによれば、この仕組みはワークロードが「TLS クライアント証明書の身元を、短命な OpenAI アクセストークンに交換する」ものだ。設定は次の流れになる。
- Mutual TLS 設定から、信頼するルート証明書をアップロードする
- 検証済み証明書から
openai.*属性を導出する X.509 プロバイダーを作成する(openai.subjectの変換式は必須) - 導出した身元を、プロジェクト内のサービスアカウントにマッピングする
mtls.auth.openai.comで証明書をベアラートークンに交換するmtls.api.openai.comに対し、トークンとクライアント証明書の両方を使って API を呼ぶ
mTLS 側は証明書の信頼検証、証明書提示の強制、ポリシーレベルのアクセス制御を担う。ガイドには「ベアラートークンと証明書はそれぞれ独立に認可される」と明記されており、両方が揃って初めて API 呼び出しが通る。
開発者への影響
最大の変化は、長期の API キーを発行してどこかに保管する運用から離れられる点にある。キーの保管場所、ローテーション、漏洩時の失効といった設計課題が、証明書の管理に置き換わる。
トークンが短命であること、そして証明書とトークンが独立に認可されることから、キー1本の流出がそのまま API 利用権限の流出になる状況を避けやすくなる。
なお、公式ガイドには Codex がこの方式に対応していない旨の記載がある。導入を検討する際は、社内で使っているツールが対応済みかを個別に確認する必要がある。
