Log for Ubuntu 台灣社群
Cloudflare 向所有客戶開放自行管理式 OAuth （★ 124 分）
Cloudflare 宣布將自行管理式 OAuth（開放授權標準，用於讓第三方在使用者同意後，以限定範圍存取資源）開放給所有客戶，目標是擴大其應用生態系。Cloudflare 表示其服務協助維持約 20% 的 Web 運作，開發者長期透過 Cloudflare API（應用程式介面）建立自動化、CI/CD（持續整合與持續交付/部署）與各種整合；過去第三方 OAuth 只提供給少數人工審核上線的夥伴，例如 Wrangler 與 PlanetScale，其他開發者多半得使用 API token（存取權杖）。新機制讓開發者可自行建立 OAuth 應用，讓客戶直接授予限定權限，適用於 SaaS（軟體即服務）整合、企業內部開發平台與代理式工具（agentic tools，可代使用者執行任務的自動化或 AI 工具），也讓授權內容、撤銷機制與應用所有權更清楚。
為了安全擴大開放，Cloudflare 先改善同意授權畫面，讓使用者更清楚看到哪個應用要求哪些權限，並在儀表板加入撤銷功能、提高應用所有權可見度，以降低 OAuth 釣魚風險。底層則需要升級 Hydra（Ory 維護的開源 OAuth 引擎）：團隊先從舊版升至最新 1.X，再升至 2.X，避免一次大改造成中斷。1.X 升級遇到資料庫結構描述遷移會對關鍵資料表加排他鎖、舊 SDK（軟體開發套件）以 SQL（結構化查詢語言）SELECT * 造成反序列化問題，Cloudflare 因此改寫遷移流程，使用 CREATE INDEX CONCURRENTLY 等方式，並自製只選取明確欄位的 Hydra 版本。
2.X 升級無法採原地升級，Cloudflare 改採藍綠部署（blue-green deployment，以新舊兩套環境切換降低風險）。如果升級期間停寫資料庫，使用者可能無法授權或撤銷應用；若不停寫，又可能在切換時遺失部分寫入。因此團隊延長 token 有效時間以減少 token 更新寫入，並用 Cloudflare Queues（Cloudflare 的訊息佇列服務）建立撤銷事件佇列，在切換後重放升級視窗內的撤銷動作，避免已被撤銷的應用重新取得存取權。實際執行時，1.X 切換後因 Hydra 對重複使用 refresh token 更嚴格，Wrangler 與 MCP（Model Context Protocol，常用於 AI 工具連接外部工具與資料的協定）高流量 client 出現更多更新錯誤，Cloudflare 以 Cloudflare Worker（邊緣運算執行環境）暫存並合併重試請求緩解；2.X 正式環境遷移約耗時三小時，切換後一度因 Hydra 遷移問題使部分有效 OAuth 工作階段被標記失效、導致 403 增加，團隊透過資料還原與授權邏輯改進修正。
升級完成後，Cloudflare 公布效能指標顯示系統資源使用下降：資料庫遷移約更新 1.325 億筆資料列、插入 1.147 億筆資料列；Hydra API 的 P95（第 95 百分位延遲）平均從 185ms 降至 101ms，減少 45%，RSS 記憶體（常駐集合大小，代表程式佔用實體記憶體）下降 14%，Go heap allocation（堆積記憶體分配量）下降 40%，goroutine（Go 的輕量並行執行單元）數量下降 23%，CPU 使用量下降 37%。Cloudflare 將這次升級視為 6 月 3 日開放自行管理式 OAuth 的基礎工程，讓所有客戶能在儀表板建立 OAuth 應用，而不必再等待人工審核成為合作整合。
Hacker News 討論對此反應分歧。支援者認為 OAuth 比到處複製 API token 更安全，因為使用者可在授權頁面檢視範圍、第三方不需直接接觸長期金鑰，也較容易撤銷；Ory Hydra 作者也現身肯定 Cloudflare 在此規模下的升級與 2.X 效能。批評者則擔心把基礎設施帳號權限委派給第三方服務，可能帶來濫用與成本風險，並指出 AWS 常見作法是透過 OIDC（OpenID Connect，建立在 OAuth 2.0 上的身分驗證協定）與 IAM（Identity and Access Management，身分與存取管理）角色限制工作負載，而非讓一般第三方 OAuth client 直接代為操作基礎設施；也有人認為對簡單的伺服器對伺服器 API 存取，具範圍限制、輪替、稽核紀錄與快速撤銷的金鑰體驗仍更直接。另有留言提醒，這次功能是為了授權第三方存取 Cloudflare 帳號與 Cloudflare API，不是替自家 App 提供一般「使用 Cloudflare 登入」的身分服務；更宏觀的疑慮則集中在 OAuth 複雜度、集中式身分的隱私風險，以及 Cloudflare 從 CDN/DDoS 防護走向更完整雲端平台後，是否會讓網路基礎設施更加集中。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=48668033
Cloudflare 宣布將自行管理式 OAuth（開放授權標準，用於讓第三方在使用者同意後，以限定範圍存取資源）開放給所有客戶，目標是擴大其應用生態系。Cloudflare 表示其服務協助維持約 20% 的 Web 運作，開發者長期透過 Cloudflare API（應用程式介面）建立自動化、CI/CD（持續整合與持續交付/部署）與各種整合；過去第三方 OAuth 只提供給少數人工審核上線的夥伴，例如 Wrangler 與 PlanetScale，其他開發者多半得使用 API token（存取權杖）。新機制讓開發者可自行建立 OAuth 應用，讓客戶直接授予限定權限，適用於 SaaS（軟體即服務）整合、企業內部開發平台與代理式工具（agentic tools，可代使用者執行任務的自動化或 AI 工具），也讓授權內容、撤銷機制與應用所有權更清楚。
為了安全擴大開放，Cloudflare 先改善同意授權畫面，讓使用者更清楚看到哪個應用要求哪些權限，並在儀表板加入撤銷功能、提高應用所有權可見度，以降低 OAuth 釣魚風險。底層則需要升級 Hydra（Ory 維護的開源 OAuth 引擎）：團隊先從舊版升至最新 1.X，再升至 2.X，避免一次大改造成中斷。1.X 升級遇到資料庫結構描述遷移會對關鍵資料表加排他鎖、舊 SDK（軟體開發套件）以 SQL（結構化查詢語言）SELECT * 造成反序列化問題，Cloudflare 因此改寫遷移流程，使用 CREATE INDEX CONCURRENTLY 等方式，並自製只選取明確欄位的 Hydra 版本。
2.X 升級無法採原地升級，Cloudflare 改採藍綠部署（blue-green deployment，以新舊兩套環境切換降低風險）。如果升級期間停寫資料庫，使用者可能無法授權或撤銷應用；若不停寫，又可能在切換時遺失部分寫入。因此團隊延長 token 有效時間以減少 token 更新寫入，並用 Cloudflare Queues（Cloudflare 的訊息佇列服務）建立撤銷事件佇列，在切換後重放升級視窗內的撤銷動作，避免已被撤銷的應用重新取得存取權。實際執行時，1.X 切換後因 Hydra 對重複使用 refresh token 更嚴格，Wrangler 與 MCP（Model Context Protocol，常用於 AI 工具連接外部工具與資料的協定）高流量 client 出現更多更新錯誤，Cloudflare 以 Cloudflare Worker（邊緣運算執行環境）暫存並合併重試請求緩解；2.X 正式環境遷移約耗時三小時，切換後一度因 Hydra 遷移問題使部分有效 OAuth 工作階段被標記失效、導致 403 增加，團隊透過資料還原與授權邏輯改進修正。
升級完成後，Cloudflare 公布效能指標顯示系統資源使用下降：資料庫遷移約更新 1.325 億筆資料列、插入 1.147 億筆資料列；Hydra API 的 P95（第 95 百分位延遲）平均從 185ms 降至 101ms，減少 45%，RSS 記憶體（常駐集合大小，代表程式佔用實體記憶體）下降 14%，Go heap allocation（堆積記憶體分配量）下降 40%，goroutine（Go 的輕量並行執行單元）數量下降 23%，CPU 使用量下降 37%。Cloudflare 將這次升級視為 6 月 3 日開放自行管理式 OAuth 的基礎工程，讓所有客戶能在儀表板建立 OAuth 應用，而不必再等待人工審核成為合作整合。
Hacker News 討論對此反應分歧。支援者認為 OAuth 比到處複製 API token 更安全，因為使用者可在授權頁面檢視範圍、第三方不需直接接觸長期金鑰，也較容易撤銷；Ory Hydra 作者也現身肯定 Cloudflare 在此規模下的升級與 2.X 效能。批評者則擔心把基礎設施帳號權限委派給第三方服務，可能帶來濫用與成本風險，並指出 AWS 常見作法是透過 OIDC（OpenID Connect，建立在 OAuth 2.0 上的身分驗證協定）與 IAM（Identity and Access Management，身分與存取管理）角色限制工作負載，而非讓一般第三方 OAuth client 直接代為操作基礎設施；也有人認為對簡單的伺服器對伺服器 API 存取，具範圍限制、輪替、稽核紀錄與快速撤銷的金鑰體驗仍更直接。另有留言提醒，這次功能是為了授權第三方存取 Cloudflare 帳號與 Cloudflare API，不是替自家 App 提供一般「使用 Cloudflare 登入」的身分服務；更宏觀的疑慮則集中在 OAuth 複雜度、集中式身分的隱私風險，以及 Cloudflare 從 CDN/DDoS 防護走向更完整雲端平台後，是否會讓網路基礎設施更加集中。
👥 49 則討論、評論 💬
https://news.ycombinator.com/item?id=48668033