Vercel 設下靜態憑證期限：OIDC 如何運作，哪些 Marketplace 服務將被警示？
Vercel 推動 OIDC 短效身分驗證，並對 Marketplace 供應商訂下 11 月 30 日警示與 2027 年 1 月下架期限。整理信任政策、OIDC UI、Connect、交換延遲及既有金鑰遷移條件。
AI 代理要查資料、部署網站或操作服務，常靠 API 金鑰取得呼叫權限。Vercel OIDC 新政策把這些長期保存的金鑰，推向以短效身分取代的方向。
這串金鑰若長期不變，一旦被程式、相依套件或錯誤的工具流程讀走，攻擊者就可能一直用到它被撤銷為止。
Vercel 在 2026 年 10 月 22 日公布新政策，推動以 OIDC 短效身分憑證取代長效金鑰，並替 Marketplace 供應商設下驗證方式的期限。
這不是所有 API 金鑰同一天失效，而是符合公告條件的 Marketplace 服務，將先被標示不安全，之後可能從市場下架。
我會先檢查團隊依賴的服務能否接受短效身分、權限能否縮到實際工作，再安排遷移，而不把換一種憑證視為風險已經消失。
要知道哪些工作真的能少留一把長效金鑰，得先看短效身分憑證如何讓兩個服務認得彼此。
Vercel OIDC 如何取代長期保存的 API 金鑰？
OIDC 讓應用程式拿到由可信發行者簽發的短效身分憑證，再由接收服務核對身分並決定權限。OIDC 是一套傳遞與驗證身分的標準，這裡用來讓服務辨識發出請求的應用程式。
官方政策文章把問題放在長效秘密的保存方式。應用程式若一直重用同一把金鑰，攻擊者取得副本後，就可能用同樣權限呼叫服務，直到金鑰被撤銷或失效。
把金鑰加密保存，可以保護它靜止放在儲存系統時的狀態，但應用程式真正使用它時，仍可能被惡意程式讀取。因此，原文強調不能只因為資料庫有加密，就當作執行中的憑證不會暴露。
短效方式改變的是這段有效時間。應用程式不必一直保存上游服務的長效金鑰，而是取得一份有期限的身分證明，再交給接收方驗證或交換成暫時權限。
到期會縮短使用窗口，但不會替權限做決定
即使短效憑證被竊，副本也會在到期後停止生效，這能限制攻擊者沿用同一份憑證的時間。但在有效期間內，它仍代表某種權限，所以能做哪些事依然需要設定。
這也解釋為什麼輪替外洩金鑰很麻煩。多個系統若共用同一把長效金鑰，撤銷時就得協調所有使用者，漏掉一處便可能讓正式服務中斷。
短效身分讓程式能自行取得新的有效憑證，減少人工分送長效金鑰的需求。不過，接收服務要先願意接受這種身分，整條路線才會成立。
憑證會到期只能縮短被竊後的使用時間，因此接下來還要看接收服務究竟信任哪個專案與環境。
信任政策與權限範圍為什麼仍要設定？
接收服務必須明確信任指定的來源與環境，不能只因為憑證來自 Vercel 就接受所有要求。信任政策就是把「誰、從哪個工作環境、可以換到什麼權限」寫成接收方會檢查的條件。
例如，正式部署與測試預覽可能屬於同一專案，但用途不同。若服務只應讓正式環境寫入，就不能把所有環境都放進相同的信任範圍，否則短效只是縮短了時間，並沒有縮小可執行的工作。
官方也提供自訂接收對象，讓憑證指明要交給哪個服務。這個欄位的用途，是避免原本發給一個服務的身分證明，被另一個不相干的接收方拿來當作同樣授權。
Vercel 的身分聯邦功能自 2024 年就已正式開放，可以在設定好的信任政策下，交換 AWS、Google Cloud 或 Azure 的暫時憑證。這次政策在既有短效交換之上，進一步擴大工具支援與 Marketplace 要求。
官方文件還區分團隊專屬與全域的身分發行者。這會影響接收服務要信任哪個來源，因此遷移時不能只複製另一個專案的設定，而不確認它對應的團隊與環境。
本機開發也可以建立相應信任，減少把長效雲端金鑰存進電腦。不過，本機、預覽與正式環境仍是不同來源，允許本機取得開發用資料，不應自動等於允許它修改正式資料。
使用者授權與部署身分不是同一件事
當應用程式要代表某個人使用外部服務，還得知道那個人的帳號是否已連接，以及服務允許哪些權限範圍。部署身分能證明程式從哪裡來，不會憑空替使用者創造新的資料存取權。
原文以 Connect 取得使用者的 Linear 權杖為例，前提包括連接器已設定、已連到專案，而且使用者帳號已完成連接。請求也只能使用供應商支援的權限。
因此，少保存一把金鑰和免除所有授權程序，是不同主張。前者是這次要改善的憑證管理，後者則不是官方公告承諾的結果。
信任範圍設好後，開發者還需要一套容易維護的設定方式，否則最省事的長效金鑰仍可能被留下。
OIDC UI 與 Connect 分別解決什麼問題？
OIDC UI 協助服務供應商建立信任設定與驗證程式，Connect 則協助應用程式在執行時取得已連接服務的權杖。它們面向不同角色，並不是兩個可以互相替換的登入按鈕。
OIDC UI是一套可加入產品的介面元件與伺服器驗證程式。供應商可以提供表單，讓客戶設定可信的專案與環境，再用對應程式核對收到的憑證。
官方列出 Vercel、GitHub、GitLab、Google、Bitbucket、AWS、Azure 與自訂發行者等表單。這能減少供應商自己從頭設計設定介面的工作，但仍要把驗證與服務的實際授權接起來。
如果只做出漂亮表單，接收服務卻沒有用政策檢查請求，使用者填過設定仍不能形成真正限制。因此元件協助的是建置流程，不能代替供應商完成整個系統整合。
Connect 處理執行時的供應商權杖
Connect 文件則面向應用程式與代理，讓它們使用部署身分，在工作需要時取得已連接供應商的權杖，不必把上游長效秘密放在環境變數裡。
這種分工讓應用程式只要求當前工作需要的服務權限，連接與更新權杖則交由 Connect 處理。但服務支援程度、使用者連接與權限設定仍是前提，不能推論任何網站都能直接接上。
Vercel 也表示正在擴充 API 與命令列的 OIDC 支援，降低部署流程保存長效 Vercel 權杖的需求。這是官方列出的推進工作，不代表每一個既有整合都已完成相同遷移。
這些工具降低設定成本，但正式採用時還要計算取得或交換權杖對執行速度的影響。
短效驗證會讓每次請求都變慢嗎？
短效驗證不一定每次都要重新連網，但自訂接收對象與供應商交換仍可能需要網路請求。效能差別來自憑證在哪裡取得，以及能重用多久，而不只是它有沒有到期時間。
原文說，Vercel Functions 會在請求標頭收到平台簽發的權杖，軟體工具組可以直接讀取，不需要為了拿這份平台身分再發一次網路請求。
平台也會重用尚未到期的權杖，Connect 則在程序內快取供應商權杖，接近到期時再更新。這些安排減少反覆取得的工作，但不能讓所有交換步驟都變成沒有網路成本。
官方另以 Azure Cosmos DB 為例，先讓 Azure 信任指定的 Vercel 專案，再由 Azure 的工具組把 Vercel 身分交換成資料庫使用的存取權杖。
這個例子的重點，是資料庫不再依賴一把長期放在應用程式裡的資料庫金鑰。它沒有提供能套用所有服務的固定延遲數字，也不能證明每一種交換都比讀取本機變數快。
OIDC 文件列出，函式使用的權杖有效期為兩小時，平台最多重用九十分鐘，剩餘時間用來涵蓋函式執行。這是該類平台權杖的安排，不能套成每家供應商交換後的權杖都一樣長。
因此，持續工作的代理不能假設一開始取得的憑證永遠有效。若一次任務跨過更新時間，應由對應工具取得當下有效的身分，而不是一直重用自己先前保存的副本。
文件也提供讀取輪替憑證檔案的方式，讓長時間執行的程序不必為了更新檔案而重新啟動。軟體工具組會在需要時讀取目前內容，開發者不應另外把回傳值永久快取起來。
在 @vercel/oidc 4.0.0 以上版本，工具會先讀請求當下的 x-vercel-oidc-token 標頭，也就是隨請求附上的身分資料。沒有這份權杖時，才轉而讀指定的輪替檔案。
如果此時指定檔案無法讀取或內容是空的，工具會回報錯誤，而不是默默改用環境變數中的舊值。這讓更新失敗能被看見，避免表面仍能呼叫服務，實際卻一直用錯的身分。
憑證管理會進入正常的請求路徑
當權限需要在執行時取得，開發者就要理解憑證是否有效、交換是否成功，以及上游服務是否接受該身分。這些資訊也能協助分辨，是業務程式出錯，還是驗證條件沒有接好。
因此，遷移應把身分取得與實際服務呼叫一起看。只測到應用程式能拿到一份權杖，還不足以證明它能以需要的權限完成工作。
效能處理說明了怎麼遷移，公告中的期限則決定供應商何時必須把這條路準備好。
11月30日與2027年1月期限適用誰？
公告針對 Vercel Marketplace 供應商的驗證方式，先設警示期限，再設下架期限。這項要求適用市場列出的服務與平台整合。
第一個時間點是 2026 年 11 月 30 日。依原文條件，不支援從 Vercel 到自己服務的 OIDC 驗證，且仍使用長效秘密驗證的供應商，將在服務列表顯示「Not secure」訊息。
第二個時間點寫的是到 2027 年 1 月，不提供安全驗證的供應商將被下架。原文沒有給一個可改寫成 1 月 1 日的精確日期，也沒有說既有金鑰會在該日全部失效。
Vercel 同時說，自己的 API 與原生整合也接受相同標準。因此這不只是要外部服務改設定，但仍需逐一確認每項服務實際推出的支援與遷移方式。
調查數字不能直接代表全產業
文章表示，Vercel 調查一千多家軟體服務供應商，只有 8.4% 支援它所稱的安全驗證方式。這是公司公開的調查結果，適用範圍限於該次調查，不能延伸成全球只有這個比例的網站安全。
這個數字的用途，是說明官方認為工具、延遲與供應商誘因都需要改善。它並沒有把所有未支援 OIDC 的產品直接判定已經發生外洩，也不是每一位讀者現有系統的風險評分。
因此，團隊應逐一確認依賴服務的驗證支援與遷移時程，才知道市場政策會影響哪一段工作。
既有應用程式該先確認哪些遷移條件？
既有應用程式應先核對服務支援、專案信任與實際權限，再確認舊長效金鑰還在哪些流程被使用。這個順序能讓遷移回到真正需要完成的工作。
以部署後查詢資料的流程為例，團隊先要知道接收服務能接受哪一種身分，再把正確專案與環境加入信任。取得短效憑證後，也應確認它只能執行原本需要的查詢，而不是取得更大的權限。
如果舊金鑰仍被另一個排程或測試流程使用，直接刪除就可能造成中斷。因此，新的身分路線可用之後，仍要找出哪些呼叫已經移轉、哪些尚未移轉，才能安排撤回舊憑證。
延伸閱讀：Railway 環境變數外洩風險：換 API 金鑰與重新部署，為什麼是兩件事？
這和 Capy 使用短效雲端憑證處理代理存取的方向相近，但這次新事件還包含 Marketplace 供應商的標示與下架要求，適用範圍與時間點應分開確認。
延伸閱讀：Capy 0.5 更新：Claude 訂閱可帶進來，OIDC 雲端憑證與免費範圍怎麼看？
我會把遷移是否完成，判定在正常工作已能取得短效權限、舊金鑰不再被依賴，而不是設定頁多了一個 OIDC 開關。
Vercel OIDC 常見問題 FAQ
11月30日所有 API 金鑰都會失效嗎？
不會。這份 OIDC 公告是針對符合條件的 Vercel Marketplace 供應商顯示安全標示，不是全網金鑰統一停用。
OIDC 代表不會有憑證外洩嗎？
不是。短效能限制同一份被竊憑證的有效時間，但信任條件、權限大小與實際系統存取仍需要設定。
使用 Connect 就不需要使用者授權嗎？
仍要有供應商支援、連接器與專案設定，以及使用者帳號連接。部署身分不會自行增加使用者原本沒有的權限。
