Vercel 市集淘汰長效金鑰，不換短效身分的服務先警示再下架

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2018 年前後，Chrome 對純 HTTP 網頁掛上「Not secure」標籤，再配上期限，幾年內把全網推向加密連線。2026 年 10 月 22 日，Vercel 技術長 Malte Ubl 在官方部落格發表《Death to long-lived static credentials》，宣布要把同一套劇本搬到服務與服務之間的驗證：Marketplace 市集供應商若不支援 OIDC 短效身分、又繼續用長效金鑰驗證，清單將從 2026 年 11 月 30 日起掛上同款「Not secure」訊息；到 2027 年 1 月，Vercel 會把不提供安全驗證的供應商下架。公告發布日與生效日是兩件事：政策在 10 月 22 日定調，警示 11 月 30 日才開始，下架落在 2027 年 1 月。

Chrome 治好了 HTTP，Vercel 想用同一帖藥治金鑰

這個類比就寫在公告裡，是公告自己的論證骨架。原文寫得直接：HTTPS 能夠普及，不是光靠它比較好用，還靠 Chrome 給純 HTTP 掛了「Not secure」標籤、設下期限；現在 Vercel 也要設自己的期限。公告同時給出現況判斷：服務與服務之間的驗證，今天很像 2010 年的 HTTPS，少數廠商與企業走在前面，許多 SaaS 與基礎設施供應商仍以長效靜態憑證為預設。

所謂長效靜態憑證，就是放在環境變數裡用了很多個月的 API 金鑰、資料庫密碼。它們的風險在使用當下：惡意程式碼只要能在正式環境讀到應用程式的憑證，靜態加密救不了什麼。Vercel 也交了自己的學費，公告寫明他們曾為幾次非常痛苦的金鑰輪替，花掉數千個工程小時，而且不想再來一次。

11 月 30 日的警示有兩個前提，缺一個都不成立

先看前後差異：在這份公告之前，市集清單上沒有任何安全標示，長效金鑰是許多供應商與使用者的預設；之後，清單本身會說話，不安全的驗證方式直接攤在列表上。期限的精確條件值得逐字看，因為它比「不支援 OIDC 就下架」的轉述窄得多。公告原文的條件是：不支援「從 Vercel 到自家服務」的 OIDC 驗證，而且仍以長效秘密作為驗證方式的供應商，才會在清單上看到 Not secure 訊息。換句話說，已經接受 OIDC 權杖、或願意把 Vercel 身分換成暫時憑證的服務，不在警示範圍；用長效金鑰但同時提供安全選項的，也不在範圍內。

Pin

到了 2027 年 1 月，條件放寬成「不提供安全驗證的供應商將面臨下架」。公告沒有給 1 月裡的確切日期，也沒有說任何既有金鑰會在那天生效失效。就公告措辭判斷，這兩個期限影響的都是市集清單的標示與存續，不是金鑰本身的效力：下架移除的是清單頁面，客戶手上的金鑰不會因為下架而集體陣亡。這一層是從公告全文推出的結論，公告原文並沒有明寫。

還有一句常在轉述時漏掉：Vercel 把自家 API 與原生整合同樣納入這個標準。這代表政策不只指向外部供應商，Vercel 自己的部署流程也在同一張時間表上，公告也承認 API 與命令列的 OIDC 支援正在擴充中，還沒有全部到位。

不受影響的人也該講清楚：如果你的服務不經過 Vercel Marketplace 整合，只是自己拿長效金鑰呼叫第三方 API，這次公告對你沒有強制力，它改的是市集的上架條件，不是全網的技術規範。

8.4% 的調查數字，與官方認定的三個障礙

支撐這次政策的調查只有一句話：Vercel 訪查了超過 1,000 家 SaaS 供應商，發現只有 8.4% 支援他們定義的安全驗證方式。這是 Vercel 自己做的調查，方法學沒有揭露，8.4% 也只代表那一次調查的範圍，不能直接換算成全產業只有不到一成的服務採用安全驗證。但作為政策動機，它足夠了。

更有資訊量的是官方對「為什麼大家不換」的診斷，三個障礙各自對應一項這次同步推出的東西。工具與設定太麻煩，對應的是 OIDC UI，一套 shadcn/ui 元件庫，供應商可以直接取得 Vercel、GitHub、GitLab、Google、Bitbucket、AWS、Azure 與自訂發行者八種表單，讓客戶設定信任政策，再用隨附的伺服器端驗證程式核對進來的權杖，不必自己從頭打造設定介面與驗證碼。官方給的使用情境很具體：供應商可以讓客戶只信任某個 Vercel 專案的正式環境，之後所有進來的權杖都按這份政策檢查。取得權杖的延遲，對應的是平台層的安排：函式收到的平台權杖直接放在請求標頭裡，SDK 讀它不必多打一次網路請求，平台也會重用尚未到期的權杖。廠商缺乏動機，對應的正是市集期限本身，不上架就沒有曝光。

代理才是這份公告的主角

表面上是基礎設施政策，讀完全文會發現真正的動機段落全部在講代理（agent）。公告寫道，當代理承擔愈來愈多有用的工作，我們交給它們的憑證，權限往往遠超過手上那件任務需要的水準。外洩路徑也列得具體：憑證可能隨程式碼進到程式庫或對話紀錄裡，也可能在服務或相依套件淪陷時跟著外流，提示注入（prompt injection）更可能誘使代理自己把憑證透露出去。長效金鑰一旦落在攻擊者手上，直到撤銷或到期之前都有效，攻擊者可以用同樣的權限一直呼叫下去；短效身分改變的正是這段有效時間，讓外洩的副本自己過期。

代理時代對憑證管理的需求，正是這次兩樣新工具的出發點。Vercel Connect 讓應用程式與代理用自己的部署身分，在執行當下向已連接的服務索取權杖，不必把上游供應商的長效秘密塞進環境變數。以 Linear 為例，官方示範的程式碼是一行 getToken 呼叫，指定使用者與 read 權限範圍；前提是連接器已設定、已連到專案，而且那個使用者的帳號已經完成連接。權杖的身分類型也有三種選擇：代表服務本身的 app、代表特定使用者的 user，以及攜帶外部身分的 jwt-bearer，同一個連接器可以視任務切換。目前可連接的供應商包括 Slack、GitHub、Linear、Microsoft、Snowflake 與 Salesforce，OAuth 客戶端由 Vercel 註冊，開發者不必自己管理 client secret。

Pin

但 Connect 有一條官方自己寫下的誠實界線，值得抄下來：把憑證存進 Connect，保留的是那把憑證既有的權限。換句話說，搬進 Connect 不會自動縮小授權範圍，原來那把金鑰能讀寫什麼，代理換到的權杖就能讀寫什麼；權限最小化要靠信任政策與 scopes 自己設定。這與許多團隊管理多把 AI 服務金鑰的痛是同一件事，先前介紹過的 New API 自架閘道是把金鑰集中在單一端點管理，Vercel 這套則是把「誰能拿什麼權限」畫進平台信任政策，兩者解的是不同半邊的問題。

短效身分實際運作時長什麼樣

OIDC 聽起來抽象，拆成三件事就夠用：可信發行者簽一張有期限的權杖證明「這個請求來自哪個應用程式」；接收端服務核對這張權杖；信任政策決定「哪個專案的哪個環境可以換到什麼權限」。自訂受眾（custom audience）再把每張權杖限定給指定的接收服務，避免 B 服務拿著發給 A 服務的身分去充當授權。發行者還分為團隊專屬與全域兩種，團隊專屬的簽發 URL 每個團隊不同，接收端要信任的對象也跟著不同，遷移時直接複製別的專案的設定，可能會對到錯的發行者。

時間參數在官方 OIDC 文件寫得很明確：函式使用的權杖有效期兩小時，平台重用上限 90 分鐘，剩餘的 30 分鐘是為了涵蓋函式的最長執行時間。也就是說，平台不會每次執行都換新權杖，但也不會讓同一張權杖用超過 90 分鐘。本機開發環境也在這套設計裡：文件明言可以設定雲端供應商信任本機開發環境，讓長效雲端憑證不必存進每台開發機。

Pin

工程上要注意的細節在 SDK。@vercel/oidc 從 4.0.0 版起，getVercelOidcToken 會先讀請求當下的 x-vercel-oidc-token 標頭，沒有標頭才轉讀指定的輪替檔案。檔案讀不到、或內容是空的，SDK 會直接丟出錯誤，不會默默退回環境變數裡的舊值；官方文件還特別提醒不要把回傳值快取起來。對長時間執行的代理來說，這代表跨越權杖更新期限的任務要在程式裡重新取用當下有效的身分，而不是抱著開工時拿到的那一份用到底。

延遲帳也要算清楚。平台權杖隨請求標頭進來是零額外往返，但自訂受眾與供應商交換仍需要網路請求，公告自己承認這是障礙之一。官方給的範例是 Azure Cosmos DB：先讓 Azure 信任指定的 Vercel 專案，再用 Azure 工具組把 Vercel 身分換成資料庫用的存取權杖，資料庫端從此不必依賴一把長期放在應用裡的金鑰。

這份期限其實鋪了兩年

把 changelog 排起來看，期限不是突然落下來的。OIDC 聯邦（federation） 2024 年 10 月 23 日就正式可用，讓 Vercel 上執行的應用憑交換取得 AWS、Google Cloud、Azure 的暫時憑證；2026 年 6 月 1 日 Vercel Blob 加入 OIDC 驗證；6 月 23 日自訂權杖受眾上線；到 10 月 22 日才宣布市集期限。工具鏈先就位，規則後到，這個順序本身就是訊號：接下來得動起來的是市集裡的供應商，包含清單上可見的 DeepInfra、fal、ElevenLabs、Exa、LMNT、PPLX API 這類 AI 服務，以及 Neon、Redis、MotherDuck 等資料庫與 Checkly、PostHog 等觀測工具。

AI 應用開發者是這波變動裡最該留意的族群之一。如果你的代理或應用跑在 Vercel 上，又依賴市集整合取用 AI 服務，供應商未來幾個月要不要支援 OIDC，直接決定你常用的整合會不會先掛警示、再從清單消失。與 OpenAI Agents API 那類代管執行環境把沙盒與框架綁在一起不同，Vercel 選的路是把身分與權限畫在部署層，讓框架自己選。

三種讀者現在各自要查什麼

只是使用市集整合的人，現在不必動，但要開始記錄自己依賴哪些整合，11 月 30 日後對照清單上的安全標示，掛著 Not secure 標示的項目提前找替代品或準備自建呼叫，也可以直接問供應商何時支援 OIDC 或權杖交換。自己寫整合、或本身就是供應商的團隊，優先工作是盤點：環境變數裡還有幾把長效金鑰在哪些流程被讀取，接收端能不能接受 OIDC 權杖或交換後的暫時憑證，信任政策要放行哪些專案與環境，正式與預覽環境不該放在同一個信任範圍。代理與 AI 應用開發者，則可以評估把代理取用服務的路徑搬到 Connect，順手把每個連接器的 scopes 收到任務實際需要的最小範圍，這與 Codex Cloud 連私人網路的邊界思維是同一題：平台給的便利預設不等於你的安全邊界。

至於這套期限會不會像 HTTPS 一樣變成全產業標準，持平地說仍在未定之數。Chrome 當年推得動，靠的是瀏覽器市占；Vercel 的籌碼是市集曝光，對供應商的約束力取決於開發者流量集中在哪些平台。這是公告本身沒有觸及的開放問題，也是後續觀察這個政策成敗的指標。

公告沒說的事，與該回查的時間點

留白的部分照實講：8.4% 背後的調查方法、判定標準與時間都沒有揭露；2027 年 1 月的下架沒有確切日期；市集供應商目前有多少已經支援 OIDC，公告沒有給清單；OIDC UI 由 shadcn 與 Vercel 提供、原始碼公開在 GitHub，但供應商實際接入的工作量因服務而異。對照 Claude Marketplace 把商品上架與計費入口收攏的做法，Vercel 這次動的是更上游的准入規則：能不能上架，先看你怎麼驗證。

後續回查盯著兩個日期就夠：2026 年 11 月 30 日前後，回查市集清單的 Not secure 標示是否如公告上線、哪些知名整合掛上警示；2027 年 1 月，回查下架名單與 Vercel 自家 API 的 OIDC 進度。在那之前，任何「全網金鑰將失效」的說法都超出公告範圍，別轉。