OpenAI API 的憑證驗證正式上線：API 金鑰之外再加一道鎖，還能改用憑證換短效令牌、不必存金鑰

一句話看懂：OpenAI API 的 mTLS 與 X.509 身分聯合正式開放，除了 API 金鑰，現在還能要求呼叫端出示憑證，也能用憑證換短效令牌、不必長期保存金鑰。

先用白話講：mTLS 是什麼？

進公司大樓時，你刷員工證（API 金鑰）就能進去，這是目前大多數 API 的做法。但如果員工證被人撿走，撿到的人也能進。

mTLS 就像在刷卡之外，再加一道「證明你是這台機器」的關卡：只有出示公司事先登記過的憑證，警衛才放行。員工證掉了也沒用，因為撿到的人沒有那張憑證。

另一件事是 身分聯合（Workload Identity Federation）：不把長期有效的鑰匙放在機器上，而是用「已經有的身分」到櫃台換一張短效的臨時通行證，用完就失效。

發生什麼事

OpenAI 在 8 月 29 日的 API 更新日誌宣布，兩個功能正式開放（GA）：

• mTLS：啟用後，該組織或專案的請求，除了原本的 Bearer 憑證，還必須出示被接受的用戶端憑證
• X.509 工作負載身分聯合：用憑證去換短效的 OpenAI 令牌，取代長期保存的 API 金鑰

要注意：官方文件明說，mTLS 不會取代 API 金鑰，只是額外加一道檢查；X.509 身分聯合則是把「長期金鑰」換成「憑證加短效令牌」。

兩個功能怎麼分？

給開發者的技術細節

大致流程：

1. 在組織設定的 Security > Mutual TLS 上傳 PEM 格式的信任根憑證，上傳後不會立刻生效，要再「啟用」
2. 官方建議先對非關鍵專案啟用，從每個服務送真實請求驗證後，再套用到其他專案或整個組織
3. 把 API 流量改送到 mTLS 專用網址：mtls.api.openai.com（預設）、mtls-us.api.openai.com、mtls-eu.api.openai.com

curl https://mtls.api.openai.com/v1/models \
  --cert "$OPENAI_MTLS_CERT_CHAIN" \
  --key "$OPENAI_MTLS_KEY" \
  --header "Authorization: Bearer $OPENAI_API_KEY"

• 憑證要含 Authority Key Identifier，上傳時須超過一天才到期
• 可附 CEL 條件，進一步限制只接受特定欄位的憑證（例如單位名稱）
• OpenAI 不會自動抓缺少的中繼憑證，也不做 CRL、OCSP 撤銷檢查，要靠自己輪替與停用憑證
• 每個組織最多 50 個憑證物件，Private Link 目前與 mTLS 不相容
• X.509 身分聯合換令牌的端點是 mtls.auth.openai.com，不回傳 refresh token

我的看法

接案時常遇到的情況是：客戶的後端服務把 API 金鑰放在環境變數裡，一旦被誤貼進 repo 或日誌，就得緊急換鑰。mTLS 的價值在於，就算金鑰外洩，沒有憑證也呼叫不了。

不過它對小團隊的負擔不輕：要自己管憑證的發放與輪替，而且 OpenAI 不做撤銷檢查，出事時只能靠停用憑證。我的建議是，個人專案或單一服務先不用急；有多個服務、或客戶有稽核要求時再導入，而且一定先在測試專案跑過一輪，確認每個服務都能出示完整憑證鏈。

名詞小辭典

• mTLS（雙向 TLS）：連線時，伺服器與呼叫端都要出示憑證，互相確認身分。
• 工作負載身分聯合：讓程式用已有的身分換取短效令牌，不必存長期金鑰。
• 信任根憑證（Trust anchor）：你事先聲明「我信任這個發證單位」的根憑證。
• CEL：一種簡短的條件運算語言，可用來設定憑證要符合哪些欄位。

資料來源

• OpenAI API Changelog（2026-08-29）
• OpenAI 文件：Mutual TLS
• OpenAI 文件：Workload identity federation
• OpenAI 文件：Configure workload identity federation with X.509 certificates