摘要： Cloudflare 在 8 月 20 日推出 OAuth scope customization，讓使用者在授權時取消勾選 optional scopes，而不是全有或全無。開發者需標示必要與選用權限，並在 token exchange 後檢查實際授予的範圍。這對 MCP server 和 AI agent 特別重要，可降低不必要的高風險授權。
長久以來，OAuth 的同意畫面都像一道只有兩個按鈕的門：應用要什麼，使用者就得全數批准，否則只能整筆拒絕。這樣的情況正在 Cloudflare 上鬆動。自 6 月以來，開發者在 Cloudflare 累計建立了數千個第三方 OAuth apps，授權次數突破一百萬；Cloudflare 在 8 月 20 日的公告則端出名為 OAuth scope customization 的新功能，讓使用者授權時能自行把某些 optional scopes 取消勾選。風險偏高的權限可以當場移除，代價不再是賠上整個整合。
對 MCP（Model Context Protocol）伺服器來說，這個痛點尤其鮮明。一個 MCP server 之所以開口要一大片權限，往往只是因為 agent「理論上」可能動用到每一項功能，但多數使用者並不打算把這麼大的存取範圍交出去。以往開發者能做的，只有自己先兜出一個 scope 選擇畫面，再把使用者導向 Cloudflare 的同意流程；如今只要把部分 scopes 標成 optional，決定權就回到使用者手裡。
問題所在：同意畫面只有全有或全無
Cloudflare 的 OAuth 實作原本就允許 client 只要求自己所設定 scopes 當中的一個子集。不過，一旦 client 拍板要要求哪些 scopes，使用者在同意畫面上就再也沒有往下縮減的空間。能選的只有兩種結局：接受完整要求，或者整個拒絕。
新設計借用的，其實是 OAuth 協定本身早已容許的彈性——授權伺服器核發的 token，scope 集合可以比要求來得更窄。Cloudflare 順著這個基礎再加一層：client owner 設定 OAuth client 時，可以逐一指定哪些 scopes 屬於 required、哪些屬於 optional。等到使用者要授權，他們就能把 optional 的那幾個取消勾選；假如某一次流程一個 optional scope 都沒要求，畫面上就與從前毫無差別。預設並未改變，核發的仍是完整的要求 scope 集合。
評估範圍是「這一次的要求」
有個細節值得盯住：required 與 optional 的判定基準，是「單一授權流程實際要求的 scopes」，而非該 client 設定裡登記的所有 scopes。Cloudflare 的例子是這樣——某個 client 設定了四個 scopes，當中有兩個屬於 optional。若某次流程四個全都要求，使用者可以只把那兩個 optional 取消掉；換成另一次流程只要求其中兩個，其餘兩個從頭到尾不會現身，也不會被強制執行。
這樣的設計讓同意畫面只圍繞當下要辦的事，而不是應用未來可能動用的每一項能力。既有 client 若沒有採用 optional scopes，行為則完全不受影響。
開發者要為「只拿到一部分」預作準備
使用者只要把任何一個 optional scope 取消勾選，換到手的 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」列為開發時的固定動作。