Cloudflare 為所有客戶推出自行管理的 OAuth
Cloudflare 為所有客戶推出自行管理的 OAuth
Cloudflare 向每位客戶開放 OAuth
Cloudflare 的全新自行管理 OAuth 功能讓任何 Cloudflare 帳號都能建立自己的 OAuth 應用程式，為開發者提供一種標準、可撤銷且基於同意的方式來存取 Cloudflare API，而不必依賴長期有效的 API 令牌。
為何通用 OAuth 重要
- 提升安全性 – 使用者可看到清晰的同意畫面，能從儀表板撤銷存取，並免於釣魚攻擊的威脅。
- 更佳的開發者體驗 – 範圍化的存取符合現代 SaaS 與內部平台工作流程，省去脆弱的 API 令牌管理需求。
- 生態系統成長 – 開放 OAuth 消除了第三方整合、代理工具與自訂自動化管線的障礙。
安全地擴展 OAuth 引擎
Cloudflare 最初的 OAuth 實作使用開源 Hydra 引擎，對於少數手動加入的合作夥伴已足夠。隨著開發者平台擴大，團隊發現了三個關鍵缺口：
- 權限模型 – 先前的同意流程未能清楚將應用程式身分與授予的範圍分離。
- 撤銷體驗 – 使用者無法輕鬆查看或撤銷應用程式的存取權。
- 濫用緩解 – 引擎缺乏對大規模自動化使用的健全防護措施。
為了解決這些問題，Cloudflare 更新了同意 UI，加入儀表板撤銷控制，並讓使用者可見應用程式所有權。
Hydra 1.X → 2.X 升級策略
兩步驟升級計畫
- 步驟 1 – 1.X 遷移 – 移至最新的 1.X 版，將資料表遷移改寫為使用
CREATE INDEX CONCURRENTLY，並將SELECT *查詢改為明確的欄位清單，以避免鎖定爭用。 - 步驟 2 – 2.X 遷移 – 部署藍綠架構，以避免在處理大量資料表變更時產生停機時間。
藍綠遷移細節
- 寫入啟用方式 – 不會停用所有寫入，Cloudflare 將令牌 TTL 延長至數小時，使現有令牌在切換期間仍然有效。
- 撤銷重播佇列 – Cloudflare Queue 在遷移期間捕捉撤銷事件；切換完成後，佇列會被清空以重播任何遺漏的撤銷，防止意外重新授權存取。
執行結果
1.X 升級
- 遷移完成且未對使用者造成影響。
- 新的更嚴格的 refresh‑token 作廢機制偶爾導致令牌鏈失效；Cloudflare 透過在 Worker 中加入 refresh‑token 合併層並利用 Hydra 2.X 可設定的寬限期來緩解此問題。
2.X 升級
- 選擇請求量最低的時段作為遷移窗口；總執行時間約 3 小時。
- 切換後，一個資料清理工作錯誤地刪除了有效的 OAuth 政策資料，導致 403 回應激增。此問題已透過還原資料並改進授權邏輯得到修復。
- 在推出後快速套用了其他客戶特定的微調。
升級後的效能提升
| 指標 | 升級前 | 升級後 | Δ |
|---|---|---|---|
| API P95 延遲 | 185 ms | 101 ms | ‑45 % |
| RSS 記憶體 | 888 MB | 763 MB | ‑14 % |
| Go 堆配置 | 449 MB | 271 MB | ‑40 % |
| Goroutine 數量 | 4,015 | 3,076 | ‑23 % |
| CPU 使用率 | 1.07 cores | 0.67 cores | ‑37 % |
資料庫遷移統計亦顯示了作業規模：
- 132.5 M 筆列已更新
- 114.7 M 筆列已插入
- 使用 136.97 GB 暫存空間
- 22.2 k 筆交易提交
開始使用自行管理的 OAuth
開發者現在可以直接從 Cloudflare 儀表板或透過官方文件建立 OAuth 應用程式：
- 文件: https://developers.cloudflare.com/fundamentals/oauth/
- 儀表板連結: https://dash.cloudflare.com/?to=/:account/oauth-clients
透過允許任何客戶註冊 OAuth 用戶端，Cloudflare 為更豐富的應用生態系統、更緊密的安全性以及更順暢的整合工作流程鋪平了道路。