OAuth 的同意畫面經常是「全有或全無」：應用要求什麼，使用者就只能全部批准或全部拒絕。自 6 月以來，開發者已在 Cloudflare 建立數千個第三方 OAuth apps，並累積超過一百萬次授權。Cloudflare 在 8 月 20 日的公告中，正式推出 OAuth scope customization，讓使用者在授權時取消勾選特定的 optional scopes，風險較高的權限可以當場拿掉，而不必放棄整個整合。
這個問題對 MCP（Model Context Protocol）伺服器尤其明顯。MCP server 可能因為 agent「理論上」會用到全部功能，而要求一組很廣的權限；但多數使用者其實不想讓 agent 擁有這麼大的存取範圍。過去唯一的解法，是 app 開發者先自己寫一個 scope 選擇畫面，再把使用者送去 Cloudflare 的同意流程。現在可以把部分 scopes 標記為 optional，把選擇權交還給使用者。
問題：授權畫面的全有或全無
Cloudflare OAuth 原本就允許 client 只要求已設定 scopes 的子集；可是一旦決定要哪些 scopes，使用者在同意畫面就無法再縮小範圍。對使用者來說，體驗仍然是非黑即白：要嘛接受完整要求，要嘛整個拒絕。
新版設計保留了 OAuth 協定原本就容許的彈性：授權伺服器可以核發比要求更窄的 scope 集合。Cloudflare 在此基礎上，讓 client owner 在設定 OAuth client 時，把特定 scopes 標記為 required 或 optional。使用者授權時，可以取消勾選 optional scopes；若該次授權流程沒有要求任何 optional scopes，同意畫面會跟之前完全一樣。預設仍然會授與完整的要求 scope 集合。
只針對「這次要求」評估
有一點值得注意：required 和 optional 是對「單次授權流程真正要求的 scopes」來評估，不是 client 設定的全部 scopes。Cloudflare 舉的例子是：某 client 設定四個 scopes，其中兩個標為 optional。如果這次授權流程四個都要求，使用者可以只取消那兩個 optional；如果下一次流程只要求其中兩個，另外兩個根本不會出現，也不會被強制執行。
這個設計讓同意畫面聚焦在當下任務，而不是應用所有可能用到的能力。對沒有採用 optional scopes 的既有 client 來說，行為也維持不變。
開發者要為部分授權做好準備
使用者一旦取消了任何 optional scopes，最後拿到的 access token 只會包含他們實際同意的 scopes。開發者必須在 exchange authorization code 之後檢查實際授予的 scope 集合，不能假設要求的項目全部通過。
能夠優雅處理較窄授權的 app——例如 agent 只在自己收到的權限子集內運作——會讓使用者更願意授權。只要求真正需要的權限，其餘標為 optional，也是一個明確的信任訊號。
Cloudflare 表示，接下來幾週會把 account 與 zone 層級的角色表面擴展到幾乎所有 Cloudflare 產品，意味著更多 API token roles、account membership options 和 OAuth scopes。如果你正在建 SaaS 整合或 agent，現在就可以試用這項功能，並把「事後檢查實際 scope」當成必要的開發習慣。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。