從全有全無到任務導向:Cloudflare 為 OAuth 導入可選 scope 同意機制
Cloudflare Blog · 2026-08-20
原本的問題
Cloudflare 在 部落格文章中說明,其 OAuth 授權伺服器過去只支援「全有全無」的同意模式:使用者在授權畫面上看到一整包 scope,只能整包核准或整包拒絕,無法個別勾掉不想開放的權限。這對一般第三方 App 已經算是摩擦,對會廣泛預先請求權限的 MCP server更是明顯放大,因為 MCP server 常常把可能用到的 scope 一次全部列進 client 設定,使用者若只想開放讀取權限,也只能連寫入權限一起接受,否則整個授權流程直接失敗。
採用的方法
解法是讓開發者在建立 OAuth client 時,把部分 scope 標記為「可選」(optional),使用者在授權畫面可以自行取消勾選這些項目,系統核發的 access token 只會包含使用者實際同意的 scope 子集。關鍵設計是 scope 的核可判斷只針對「這次授權流程實際請求的 scope」進行,而不是對照 client 設定裡完整的 scope 清單,避免使用者取消一個可選 scope 卻意外連動影響其他必要權限。開發者透過 API 設定 client 時可以指定哪些 scope 屬於可選:
"optional_scopes": [
"workers-kv-storage.write",
"zone.read"
]文件中列出的 scope 命名沿用既有規則,同一個 client 可以混合必要與可選項目,例如:
user-details.read— 必要,讀取使用者基本資料workers-scripts.write— 可標記為可選,寫入 Workers 腳本workers-kv-storage.write— 可標記為可選,寫入 KV 儲存zone.read— 可標記為可選,讀取 zone 設定
實際效果
這套機制建立在 OAuth 規範本身允許「核發範圍可以比請求範圍更窄」的彈性之上,沒有引入新協定或非標準流程,因此既有 OAuth client 不需要改程式碼就能相容。Cloudflare 提到自六月起已有數千個第三方 OAuth App 上線,累積授權次數超過一百萬次,可選 scope 是在既有流量基礎上疊加的新選項,而非另起爐灶的新系統。
Microsoft 發布 Go 1.27.0-1,systemcrypto 轉為預設行為
Microsoft for Go Developers Blog · 2026-08-20
背景
微軟在 官方部落格宣布 Microsoft build of Go 新版 1.27.0-1(對應上游 go1.27.0)已可從 GitHub 的 microsoft/go 儲存庫下載。Microsoft build of Go 是微軟基於上游原始碼維護的發行版,與標準 Go 最主要的差異在加密後端:標準 Go 的 crypto 套件是純 Go 實作,Microsoft build 則會改呼叫作業系統原生、已通過 FIPS 140 驗證的加密函式庫,Linux 用 OpenSSL、Windows 用 CNG、macOS 用 Common Crypto/CryptoKit。這是為了滿足微軟內部對加密合規的要求,讓同一份 Go 程式碼在不同平台建置後都能通過稽核,不需開發者額外處理。
核心改動
此版最大的變動是 systemcrypto 不再是 GOEXPERIMENT 選項,工具鏈會自動選用,等於從「需要手動開啟的實驗功能」變成「預設行為」。原本用來開啟的環境變數 GOEXPERIMENT=systemcrypto 現在設定會直接報錯,要停用系統加密後端須改用專屬變數:
MS_GO_NOSYSTEMCRYPTO=1其餘改動涵蓋平台與演算法支援:
- 新增 FreeBSD
amd64/arm64支援,經由 OpenSSL 提供加密後端 - Linux 部分架構開放
CGO_ENABLED=0 - 新增 ML-DSA 系列後量子簽章參數集:ML-DSA-44、ML-DSA-65、ML-DSA-87
GODEBUG=fips140=only會在偵測到非 FIPS 演算法時直接 panic,fips140=off則明確關閉 FIPS 模式
影響範圍
受影響最直接的是原本依賴 GOEXPERIMENT=systemcrypto 手動開啟系統加密的建置腳本,升級後這行設定會讓建置失敗,需要整段移除或改成 MS_GO_NOSYSTEMCRYPTO=1。官方同時聲明依照 Go 官方的版本支援政策,此版起 Go 1.25 系列不再受支援,仍在用 1.25 工具鏈的專案需要規劃升級到 1.26 或 1.27 系列。