摘要： Cloudflare 在 2026 年 6 月 24 日發布 OAuth for all，讓所有客戶能建立 OAuth 應用並取得 Cloudflare API 的委派存取權。團隊把 Hydra 從 1.x 升級到 2.x，用約三小時的藍綠切換完成遷移且服務不停機，並以佇列重播升級期間的撤銷請求。完成後 API P95 延遲從 185 毫秒降到 101 毫秒。
2026 年 6 月 24 日，Cloudflare 官方部落格刊出題為「OAuth for all」的公告，自助式 OAuth 自此開放給每一位客戶：往後大家都能直接在儀表板建立自己的 OAuth 應用程式，經標準授權流程取得 Cloudflare API 的委派存取權。回頭看 6 月 3 日那一波限定開放，前後僅隔三個星期。
表面上這是一則產品發布，實際上卻把一場基礎設施工程的來龍去脈完整交了底：OAuth 引擎從 Hydra 1.x 一路換到 2.x，生產環境遷移總計約三小時，服務自始至終沒有停過。
全面開放的動機：與 API Token 分道揚鑣
過去能接上 Cloudflare 第三方 OAuth 的，只限少數經人工逐一審核的合作夥伴（Wrangler、PlanetScale）；其他開發者手上別無選擇，只剩 API Token。這種憑證治理起來吃力，也沒有為委派場景而設計——某個應用實際被授予哪些權限，使用者無從得知，想收回時更找不到現成的操作入口。
真正改變局面的，是 agentic 工具的迅速竄起。Cloudflare 說得直接：代理工具催生出委派存取的需求，把 OAuth 開放給所有客戶，已經是平台成功的必要條件。今年稍早的鋪陳其實已經展開：同意畫面重新設計，申請的應用與其要求的權限會明白列出；撤銷功能進駐儀表板；應用擁有者資訊也做得更加醒目，用來對付 OAuth 釣魚。
分兩階段推進的引擎升級
撐起 Cloudflare OAuth 引擎的，是開源專案 Hydra。團隊判定既有部署撐不住全面開放，於是安排升級，並刻意設計成兩段：先推進到 1.x 的最終版本，實際觀察它的表現，之後才迎戰 2.x 的大版本跨越。
單是第一段就不輕鬆：官方遷移程式會先對幾張關鍵資料表加獨占鎖、再搬移資料，線上操作會整個被卡住；偏偏 SDK 取值靠的是 SELECT *，欄位一有變動，反序列化馬上出錯。團隊的解法是重寫 SQL，把索引改為並行建立以繞開鎖表，並長期維護一套逐一寫明欄位的 Hydra 自訂版。
輪到 2.x 時，schema 變動的幅度已經大到無法原地升級，團隊轉向藍綠部署：先把整套遷移在資料庫副本上完整執行一遍，然後一口氣切換過去。
藍綠切換，以及為撤銷打造的佇列
方案聽來單純，難關藏在切換前後那幾個小時。最直覺的劇本是這段時間一律停止寫入，可是如此一來新的授權辦不成，撤銷也跟著停擺——若有人恰好在升級進行中急著切斷某個應用的存取，將求助無門。
他們準備了兩層防護。其一是延長新發 token 的效期，讓切換前取得的憑證足以撐過整個空窗，寫入量因此下降；其二是拿 Cloudflare Queues 組出一條撤銷重播佇列，升級視窗內發生的每一筆撤銷都先排進佇列，等綠版上線後依序補做。這一步若出差錯，後果很重：早已被使用者撤銷的應用，會在無人察覺下重新取得存取。
遷移的量體不小：更新約 1.325 億列、插入約 1.147 億列，暫存資料共 136.97 GB。切換結束後事情還沒完，團隊接著挖出一個衍生問題：新版 Hydra 對 refresh token 遭重用的判定比以往嚴格，一旦命中就作廢整條 token 鏈，受創最深的是流量大的 Wrangler 與 MCP 用戶端。他們先靠 Worker 層的請求合併撐住場面，根治則要等 2.x 內建的寬限期機制。
數字會說話：P95 延遲近乎腰斬
成績單相當亮眼：API 的 P95 延遲從 185 毫秒降到 101 毫秒，約省下 45%；常駐記憶體從 888 MB 收縮到 763 MB，Go heap 配置從 449 MB 降到 271 MB；goroutine 數量由 4,015 降為 3,076，CPU 用量也從 1.07 核滑落到 0.67 核。這場引擎汰換釋出的紅利，直接反映在每一筆請求上。
對開發者而言，實際改變了什麼
第一，日後串接 Cloudflare，不必再把自己的長效 API Token 交進別人的系統——建立 OAuth 用戶端、勾選最小權限範圍，使用者同意後即可代為操作。第二，希望 agent 能碰自家 Cloudflare 帳號的團隊，現在有一條正大光明的路：同意機制清楚，撤銷一鍵完成。第三，經營 SaaS 或內部平台的業者，終於能把 Cloudflare 正式寫進支援整合的名單。這篇公告在 6 月 25 日登上 Hacker News，獲得三百多個讚。