Workload Identity Federation 是什麼？呼叫 Claude API 不用固定 API key 的白話指南

前陣子我們團隊在 Claude Console 建一把新的 API key，畫面上多了一段提示：建議改用 identity federation，讓跑在雲端上的程式不必再保管固定金鑰；本機腳本、第三方工具、沒有身分提供者的環境，才可能還需要 API key。同事看完第一句就轉頭問：federation 到底是什麼？跟我們平常複製貼上的那串 sk-ant- 有什麼關係？

先講結論：Workload Identity Federation（工作負載身分聯合，簡稱 WIF）是讓程式「用身分換通行證」的登入方式。你的程式跑在 Google Cloud、AWS、Azure 或 GitHub Actions 上時，平台本來就會發給它一張短效的身分證明（OIDC token）。WIF 讓程式拿這張證明去 Anthropic 換一張幾分鐘到一小時就失效的 Claude 通行證，整個過程沒有任何一把「永遠有效」的金鑰需要保管。這是 Claude 官方文件對它的定位：用短效 token 取代長效的 sk-ant- API key。

打個比方。API key 像一把可以無限複製的大門鑰匙，誰撿到誰就能進門，而且門鎖不會自己換。WIF 比較像公司識別證加上當日訪客證：警衛先確認你是誰、你從哪個部門來，再發一張今天下班前有效的臨時證。證件弄丟了，明天就是一張廢卡。

這篇用零基礎的角度把整件事拆開：固定金鑰到底危險在哪、交換流程怎麼跑、能不能自己寫程式發證、KMS 與 HSM 在解什麼問題，最後把 AD、Entra ID、Okta、authentik 這幾個常被混在一起的名字分清楚。

如果你是負責採購或管 IT 的主管，不寫程式也沒關係，看懂第一張表和最後一段的判斷流程就夠用了。

Workload Identity Federation 是什麼？先用一張表看懂

一句話：WIF 把「程式拿什麼證明自己是誰」這件事，從一串藏在設定檔裡的密碼，換成由執行平台現場簽發、很快就過期的身分證明。

拆開名字來看會比較好懂。Workload（工作負載）指的是跑在伺服器上、不需要人坐在電腦前操作的程式，例如每天半夜跑的報表排程、自動部署的 CI 流水線、客服機器人的後端。你可以把它想成公司裡不用打卡的機器同事。Federation（聯合）則是「互相承認對方發的證件」，就像兩個國家簽了駕照互認，Anthropic 願意承認 GitHub 或 Google 發給你程式的身分證明。

中間那張身分證明用的格式叫 OIDC（OpenID Connect），可以把它想成一種電子身分證的國際標準：上面寫著誰發的（iss）、發給誰（sub）、什麼時候過期（exp），最後蓋上發證單位的數位簽章。實際傳遞的檔案格式叫 JWT，就是那張證件的電子檔。

要先說清楚一個邊界：WIF 管的是「程式」的身分，跟員工用帳號密碼登入 Claude 是兩回事。官方文件也提醒，federation 本身並非完整的資安方案，它的強度取決於上游那個發證單位設得好不好。發證單位本身被攻破，後面換到的通行證一樣是真的。

固定 API key 為什麼危險？金鑰外洩後帳單是怎麼爆掉的

API key 最大的問題，是它沒有「誰」的概念：拿到這串字的人就是你。很多人建立時又習慣選永不過期，一旦流出去，損害會一路持續到有人發現並撤銷為止。

流出去的量比想像中大很多。資安公司 GitGuardian 的 2026 年 State of Secrets Sprawl 報告統計，2025 年光是公開的 GitHub commit 裡，就新增了 2,865 萬筆寫死在程式碼裡的機密，比前一年多 34%。其中跟 AI 服務有關的金鑰有 1,275,105 筆，一年成長 81%，成長最快的幾類幾乎都是 AI 相關服務。

更麻煩的是外洩之後沒人收拾。同一份報告回頭檢查 2022 年就確認有效的那批金鑰，到 2026 年 1 月仍有超過 64% 可以使用。也有大約 28% 的外洩事件發生在程式碼以外，例如 Slack、Jira、Confluence 這些協作工具，因為大家趕著除錯時最常把金鑰直接貼給同事。

落到荷包上是什麼樣子？T客邦 2026 年 3 月的報導轉述了一則 Reddit 求助文：一個 3 人的小團隊不小心把 Gemini API 金鑰洩漏到網路上，原本每月大約 180 美元的帳單，48 小時內暴增到 8.2 萬美元。數位時代也提醒，用 AI 寫程式（Vibe Coding）時最常見的錯，是讓 AI 把 API key 直接寫進前端網頁，任何打開瀏覽器開發者工具的人都看得到。

金鑰外洩也會牽連客戶資料。iThome 在 2026 年 8 月報導，659 家使用 Stripe 的商家 API 金鑰流出，約 35GB、近 69 萬筆客戶紀錄被公開，Stripe 本身並沒有被駭，出事的是商家自己保管的那把鑰匙。台灣也有類似的例子，我們之前整理過 Zeabur 資安事件裡 API 金鑰是怎麼被偷走的。

三條最常見的外洩路徑

• 寫死在程式碼或前端：測試時先貼上去，上線忘了拿掉，或是放進私有 repo 以為安全，結果整個 repo 被分享給外包。
• 貼進聊天工具、工單或 AI 對話：急著請同事或 AI 幫忙除錯，整段設定檔連金鑰一起貼上，詳細流程可以看 AI 對話為什麼不能貼金鑰。
• 交接後沒有撤銷：員工離職、外包結案，金鑰還留在對方的筆電和 CI 設定裡，沒有人記得是哪一把。

把兩種做法放在一起比，差別就很明顯：

有效期限的選項來自 Claude 的驗證文件，它同時建議把 API key 放進機密管理工具、定期輪替，懷疑外洩就停用。這些都對，只是每一條都要靠人記得做。

這種「帳號和金鑰散在各處，沒人收得乾淨」的結構問題，我們在自家產品也遇過。後來的做法是把多個自有 SaaS 的登入、訂閱與授權收進同一套 恆遠會員中樞系統，新產品上架直接接進來，不再各管一套帳號。會員中樞管的是「人」的身分；WIF 處理的是同一件事的另一半，也就是「程式」的身分。想討論你公司的系統怎麼把身分集中管理，可以跟我們聊聊。

federation 怎麼運作？從拿身分證明到換到 Claude 通行證

先講結論：你在 Claude Console 登記三樣東西，程式在執行時跑三個步驟，就能完全不碰 API key 呼叫 Claude。設定要由組織的 admin 或 owner 操作，位置在 Console 的 Settings → Workload identity，裡面有一個 Connect workload 精靈會帶你一次建好。

流程拆成白話是這樣：第一步，程式向所在平台要一張 JWT。在大多數平台上這張證明是現成的，Kubernetes 會把它放在容器裡的固定檔案，Google Cloud 和 Azure 有內部的 metadata 服務，GitHub Actions 有專門發 OIDC token 的端點。

第二步，SDK 把 JWT 送到 Anthropic 的 POST /v1/oauth/token。Anthropic 會去發證單位公開的 JWKS（公開金鑰清單）抓金鑰來驗簽章，再檢查 JWT 內容有沒有符合你設定的規則，通過後回傳一張 sk-ant-oat01- 開頭的短效通行證。第三步，SDK 每次呼叫 API 都帶著這張通行證，並在到期前 120 秒先嘗試換新，到期前 30 秒還換不到才報錯。

JWKS 必須能從公網用 https、443 port 抓到；如果你的 Kubernetes 叢集在內網，可以改用 inline 模式直接把公開金鑰貼進 Console。程式這邊幾乎不用改，以 Python 為例，建立 client 時不再傳 API key，改傳身分相關的 ID：

from anthropic import Anthropic, WorkloadIdentityCredentials, IdentityTokenFile

client = Anthropic(
    credentials=WorkloadIdentityCredentials(
        identity_token_provider=IdentityTokenFile("/var/run/secrets/anthropic.com/token"),
        federation_rule_id="fdrl_...",
        organization_id="<你的組織 ID>",
        service_account_id="svac_...",
        workspace_id="wrkspc_...",
    ),
)

正式環境更常見的做法是連這幾個 ID 都不寫在程式裡，改用環境變數注入，同一個容器映像檔就能在測試與正式環境共用。

新手最常踩的三個坑

• 舊的 API key 還在環境變數裡：SDK 讀取憑證有固定順序，ANTHROPIC_API_KEY 排在 federation 前面。只要它還在，程式會默默繼續用舊金鑰，你以為導入了其實沒有。用官方 CLI 的 ant auth status 可以看到實際用的是哪一種。
• 同一張 JWT 重複使用：帶有 jti 欄位的身分證明預設只能換一次，重試迴圈拿舊的 JWT 再送，會被拒絕並在驗證紀錄上看到 jti_reused。
• 規則開太寬：subject 用萬用字元一口氣放行整個組織，任何一個 repo 的流水線都能換到通行證。規則要盡量寫窄，最好精確到 repo 和分支。

Claude 的 Workload Identity Federation 支援哪些平台？什麼情況還是得用 API key

先講結論：Console 精靈直接提供 GitHub Actions、AWS、Google Cloud、Microsoft Entra ID、Kubernetes 五種選項，其他符合標準的發證單位（例如 SPIFFE、Okta、authentik）走 Custom OIDC。真正沒有平台可以發證的地方，就是 API key 還要繼續存在的地方。

這張表也是 Console 那段提示的完整版：本機腳本、第三方工具、沒有身分提供者的環境，目前就是只能用 API key。Claude 的驗證文件寫得很直接：想快速開始就用 API key，個人開發用個人金鑰，共用的程式用 service account 金鑰；等到程式已經有平台發的身分，再換成 federation。

Okta 有一個特別的限制。Claude 的 Okta 設定文件說明，必須使用 Okta 的 custom authorization server（包含名為 default 的那一個），因為 Okta 不公開 org authorization server 的簽章公鑰，外部服務沒辦法驗證它發的 token。很多人第一次接卡關，原因就是 issuer URL 少了 /oauth2/<伺服器 ID> 這一段。

從 API key 換成 WIF，不停機的四個步驟

• 先並行設定：照精靈建好 issuer、service account、rule，舊的 API key 先留著。
• 確認誰在生效：在程式執行環境跑 ant auth status，這時應該還是 API key 勝出。
• 拿掉環境變數：把 ANTHROPIC_API_KEY 從 CI secrets、容器環境、shell 設定檔全部移除，再確認一次已改走 federation。
• 刪除舊金鑰：程式穩定跑在短效 token 上之後，到 Console 的 Settings → API keys 刪掉它。

想先試水溫的團隊，建議挑 CI 流水線當第一站。CI secrets 是最多人有權限看、也最常被複製到別處的地方，改起來影響範圍小，效果又最明顯。

能不能自己寫程式當發證單位？私鑰會變成新的那把固定金鑰

先講結論：技術上可以，Custom OIDC 接受任何符合標準的發行者。只要 JWT 裡的 iss 和你登記的 issuer URL 完全一致，公開金鑰放在 Anthropic 抓得到的 JWKS 端點（或直接貼上），自己寫的服務也能發證。問題在後面：你發證要用一把簽章私鑰，這把私鑰該放哪？

這把私鑰能簽出任何你想要的身分證明，等於能換到 Claude 通行證。如果它只是存成伺服器上的一個檔案或環境變數，你做的事情只是把「長效 API key」換成「長效私鑰」，風險原封不動往上搬了一層。Claude 的驗證文件也特別提醒：上游只要還有一把長效機密能拿來產生身分證明，整條信任鏈就可能被它拖垮。

用 Okta 或 authentik 當發證單位也有同樣的問題，只是換了形式。依照 authentik 的整合說明，程式要先用 Client ID 和 Client Secret 向 authentik 換身分證明，這組 Client Secret 一樣是需要保管的長效機密。差別在於它只能向你自己的 IdP 換證，而 IdP 可以設 IP 白名單、記錄每次發證，比一把直接能打 Claude 的 API key 好管很多。

KMS 與 HSM：把公司大印鎖進銀行保險庫

想像公司的大印。放在辦公室抽屜，誰拿到都能蓋；放進銀行保險庫，要用印時把文件送進去，行員在裡面蓋好再遞出來，印章本身永遠不離開保險庫。偷印章這條路被堵死了，剩下的風險只有「誰有資格送件」。

HSM（Hardware Security Module，硬體安全模組）就是那個保險庫：一台專門保管金鑰的硬體，金鑰在裡面產生、在裡面簽章，設計上就拿不出來。KMS（Key Management Service，金鑰管理服務）則是雲端廠商把 HSM 包裝成服務，你用 API 把要簽的內容送進去，拿回簽好的結果。以 AWS 為例，AWS KMS 文件說明它的金鑰受 FIPS 140-3 Level 3 認證的 HSM 保護，不會以未加密的形式離開 KMS；價格頁列出每把金鑰每月 1 美元，另依請求次數計費。

放進 KMS 之後，風險轉移到「誰能呼叫簽章 API」，所以權限要收緊到只有發證服務能用，並且打開稽核紀錄。另一頭的驗證方也不能偷懶，微軟之前就出過 JWT 沒驗簽章就被冒充管理員 的事件，簽章再安全，對方不驗也是白搭。

所以我們的判斷很直接：自己發證卻沒有 KMS，等於繞了一大圈回到原點，不如繼續好好管 API key；確定私鑰能放進 KMS，自己發證才划算。

IdP、AD、Entra ID、Okta、authentik 差在哪？分清楚「人的身分」和「程式的身分」

先講結論：IdP（Identity Provider，身分提供者）是一個角色名稱，指負責確認身分、發證明的那一方；AD、Entra ID、Okta、authentik 則是可以扮演這個角色的產品。它們最大的差別，在於主要管的是人還是程式，以及裝在你家機房還是放在雲端。

「人的身分」大家比較熟：員工用公司帳號登入 Email、ERP、Claude，背後是 SSO 在發證。「程式的身分」也叫 workload identity，是給排程、API、CI 流水線用的，它沒有手機可以收驗證碼，也不會自己記得改密碼。後者的數量遠比想像中多，CyberArk 2025 年身分安全調查訪問了 2,600 位資安決策者，結果是企業裡平均每 1 個人就對應 82 個機器身分，其中 42% 擁有特權或敏感權限，而 61% 的組織沒有替雲端基礎設施和工作負載建立身分安全控管。

很多人以為「中央發 token 的服務」就是 AD。嚴格來說，傳統 AD 主要靠 Kerberos 和 LDAP 在公司內網運作，它本身不會直接扮演 WIF 需要的 OIDC 發行者。要接 Claude 的 federation，通常是用雲端的 Entra ID（微軟官方說明它就是以前的 Azure AD），或是在 AD 前面加一層能發 OIDC token 的服務。

Google Cloud 自己也有同名的功能，官方文件把動機講得很白：服務帳戶金鑰是威力很大的憑證，管理不當就是資安風險，federation 就是用來免除這些金鑰的維護負擔。換句話說，各家雲端正在往同一個方向走。想把員工登入那一半也理清楚，可以接著看 企業單一登入 SSO 完整指南。

中小企業要不要導入 Workload Identity Federation？照你的狀況挑一條路

先講結論：要不要上 WIF，看的是你的程式跑在哪，跟公司規模關係不大。照下面這張圖走一遍，大多數公司三十秒內就知道該做什麼。

為什麼值得花這個力氣？Verizon 2026 年資料外洩調查報告（DBIR）的整理顯示，如果把整條入侵過程都算進去，憑證濫用出現在 39% 的外洩事件裡，仍是攻擊者最常利用的手段。IBM 2026 年資料外洩成本報告則指出全球平均每次外洩成本是 499 萬美元，超過兩成的組織回報 AI 模型或應用遭到攻擊，最常見的破口是周邊系統，其中 API、應用程式或外掛被入侵占 27%。

數字看起來離中小企業很遠，但入口其實很近：一把放在共用資料夾的 API key，就是 IBM 說的那種周邊破口。

今天就能做的五件事

• 盤點所有 API key：打開 Claude Console 的 API keys 頁面，每一把都要說得出是誰建的、哪支程式在用。說不出來的先停用，停用可以恢復，刪除不行。
• 一個用途一把，全部設到期日：別讓報表排程和客服機器人共用同一把，出事時才知道要撤哪一把。
• 開帳單上限與異常警示：這是金鑰外洩時唯一能幫你止血的保險。
• CI 流水線先改成 WIF：影響範圍最小、效果最明顯，跑順了再擴到其他服務。
• 離職與外包結案當天就撤銷：把撤銷金鑰寫進交接清單，跟歸還門禁卡放在同一步。

如果你的系統是用 AI 工具快速做出來的，金鑰常常就藏在前端或設定檔裡，上線前值得找人看一遍，Vibe Coding 做出來的 App 能直接上線嗎 列了最常見的幾個漏洞，也可以直接用我們的 Vibe Coding 健檢。程式跑在 Kubernetes 上的團隊，可以先複習 Kubernetes 是什麼，因為 projected token 就是 WIF 在 Kubernetes 上的身分來源。要參加投標或供應商稽核的公司，金鑰管理也是 ISO 27001 資訊安全管理 一定會問的項目。

剛開始用 Claude API 的新創，也可以順便看 Claude 新創計畫怎麼申請，在額度開始累積之前就把金鑰規則訂好，比事後補救輕鬆很多。

看到這裡，如果你也在想「公司裡這些 AI 串接的金鑰到底該怎麼收」，我們很樂意 聽你聊聊現在的實際情況，一起看看哪些該換成 federation、哪些維持 API key 就好。