Optional OAuth Scope Cloudflare Membuat Consent Lebih Sempit, Bukan Otomatis Aman

Cloudflare kini memungkinkan orang menolak permission OAuth opsional saat mengotorisasi Wrangler atau server Model Context Protocol (MCP) API Cloudflare. Access token hanya berisi scope yang mereka setujui. Ini adalah kontrol least privilege yang berguna, terutama ketika client agent dapat memanggil tool di luar tugas yang sedang dihadapi.

Ini bukan least privilege otomatis. Cloudflare tetap memilih seluruh set yang diminta secara default, scope wajib tidak dapat dimatikan saat consent, dan client harus memeriksa scope yang diberikan alih-alih mengasumsikan setiap request berhasil. Karena itu, tes operasionalnya sederhana: tolak setiap permission yang tidak diperlukan tugas langsung, lalu buktikan bahwa pekerjaan yang diizinkan tetap berhasil dan pekerjaan yang ditolak berhenti dengan bersih sampai pengguna sengaja melakukan reauthorization.

Scope opsional mengubah grant, bukan tingkat kepercayaan pada client

Changelog 22 Agustus Cloudflare menerapkan kontrol consent baru pada Wrangler dan server MCP API Cloudflare. Penjelasan rilis OAuth yang lebih luas menambahkan dua detail penting bagi implementer.

Pertama, label wajib dan opsional hanya dievaluasi di antara scope yang diminta dalam alur otorisasi tersebut. Client yang dikonfigurasi untuk empat kapabilitas dapat meminta dua untuk tugas yang sempit; hanya dua itu yang muncul dan diklasifikasikan untuk grant tersebut. Kedua, respons token mencerminkan pilihan pengguna yang sebenarnya. Client yang meminta empat scope tetapi menerima dua harus beroperasi dengan dua scope itu, bukan menganggap perbedaannya sebagai error authorization server.

Halaman resmi tersebut menetapkan perilaku yang diumumkan, tetapi tidak memberikan hasil kompatibilitas independen untuk kombinasi client Wrangler atau MCP saat ini. Karena itu, matriks di bawah adalah tes penerimaan untuk dijalankan, bukan klaim bahwa setiap client yang ada sudah menangani partial grant dengan benar.

Ada tiga keputusan yang terpisah:

Keputusan	Siapa yang mengendalikannya	Yang harus diverifikasi
Scope mana yang dapat diminta client	Pemilik client saat mengonfigurasi client OAuth	Set yang dikonfigurasi tidak memuat kapabilitas di luar tujuan produk yang didokumentasikan
Scope terkonfigurasi mana yang wajib	Pemilik client	Hanya set kapabilitas terkecil yang diperlukan client untuk mulai dan menjelaskan dirinya yang bersifat wajib
Scope opsional yang diminta mana yang masuk ke grant ini	Orang yang mengotorisasi alur	Layar consent sesuai dengan tugas saat ini, dan aplikasi mencatat set scope yang dikembalikan tanpa mencatat token

Fitur ini terutama memperbaiki keputusan ketiga dan memberi pemilik client mekanisme untuk keputusan kedua. Fitur ini tidak dapat menyelamatkan client yang melabeli akses tulis luas sebagai wajib. Panduan konfigurasi client Cloudflare menyatakan semua scope yang dipilih wajib secara default; pemilik harus secara eksplisit menandai sebagian scope sebagai opsional.

Wrangler mengekspos kontrol terkait tetapi berbeda. Dokumentasi perintahnya memungkinkan operator meminta set scope pilihan saat login, tetapi menggunakan semua scope yang tersedia ketika tidak ada flag scope. Meminta lebih sedikit scope mempersempit apa yang masuk ke consent. Membatalkan pilihan scope opsional mempersempit apa yang diberikan authorization server. Review least privilege harus menguji kedua jalur tersebut, bukan menganggap layar consent baru sebagai pengganti request yang sempit.

Scope yang ditolak menguji client sama seperti authorization server

Perbedaan antara scope yang diminta dan yang diberikan memang diharapkan dalam partial consent. Pertanyaan yang penting adalah apakah client menurunkan tool yang tersedia dari grant yang dikembalikan atau menganggap setiap permission yang diminta telah disetujui. Client yang berperilaku baik dapat mempertahankan fungsi dasarnya, menyembunyikan tindakan yang tidak tersedia, dan membuat peningkatan otoritas berikutnya terlihat melalui reauthorization. Client yang buruk dapat mengubah pilihan pengguna menjadi error generik, efek samping parsial, atau upaya diam-diam untuk mendapatkan kembali akses yang lebih luas.

Visibilitas client tidak menyelesaikan pertanyaan itu. Cloudflare mengatakan private client hanya dapat diotorisasi oleh anggota parent account. Public client memerlukan verifikasi domain publisher, tetapi panduan otorisasi Cloudflare mengingatkan bahwa verifikasi domain menetapkan kontrol atas domain yang ditampilkan—bukan bahwa aplikasi aman.

Cloudflare mengatakan scope yang ditolak dan kemudian menjadi diperlukan membutuhkan reauthorization. Event consent kedua itulah inti fiturnya: pengguna dapat melihat bahwa tugas berubah dan memutuskan apakah kapabilitas tambahan tersebut beralasan.

Token yang lebih kecil membatasi apa yang dapat diotorisasi token tersebut. Token itu tidak membuktikan bahwa alur otorisasi, penyimpanan token, perilaku client, atau tool downstream aman.

Overreach scope wajib tetap merupakan overreach. Pengguna tidak dapat membatalkan pilihan scope wajib. Jika client dapat menjalankan fungsi dasarnya tanpa permission tertentu, klasifikasikan permission itu sebagai opsional atau jangan memintanya.
Default tetap luas. Cloudflare memilih permission opsional yang diminta secara default. Orang yang mengeklik terus tanpa mengedit menerima seluruh set yang diminta, sehingga client harus memulai dengan request yang sempit, bukan mengandalkan setiap pengguna untuk memangkasnya.
Keamanan alur otorisasi terpisah. Cloudflare mendokumentasikan Authorization Code dengan PKCE untuk public client browser, mobile, desktop, dan command-line. Praktik terbaik keamanan OAuth terkini dari IETF juga mewajibkan PKCE untuk public client dan pencocokan persis registered redirect URI. Scope opsional tidak mencegah intersepsi authorization code, kesalahan redirect, atau cross-site request forgery.
Penanganan kredensial terpisah. Bearer token tetap memerlukan perlindungan yang sama baik pada dua scope maupun dua puluh. Dokumentasi Wrangler saat ini menawarkan penyimpanan di keychain sistem operasi; log, komentar issue, worksheet, prompt, dan konteks model harus berisi nama scope serta bukti non-rahasia, tidak pernah token atau kredensial refresh.
Grant yang aman dapat menggerakkan tool yang tidak aman. Scope opsional tidak memvalidasi argumen tool MCP, mengikat tindakan pada intent pengguna saat ini, mencegah jalur confused deputy, atau menambahkan approval sebelum panggilan destruktif. Validasi tingkat tool, batas akun dan resource, konfirmasi manusia, serta kontrol pemulihan tetap diperlukan.
Nama scope tidak dengan sendirinya mengukur konsekuensi. Satu scope tulis dapat lebih berbahaya daripada sepuluh scope baca. Tinjau resource, akun, operasi, sensitivitas data, reversibilitas, dan efek samping downstream di balik setiap nama.

Inilah pembedaan yang sama di balik analisis roadmap MCP (bahasa Indonesia): dokumentasi menetapkan mekanisme yang tersedia, sedangkan pasangan client-server yang di-deploy menentukan perilaku aktual. Analisis Claude Skills API (bahasa Indonesia) menerapkan aturan yang sama pada bundle agent yang dapat digunakan kembali.

Perubahan Cloudflare menjadikan partial consent OAuth sebagai kontrol yang dapat digunakan untuk client Wrangler dan MCP. Buktinya bukan tombol Edit Permissions yang baru. Buktinya adalah test run ketika kapabilitas yang ditolak tetap ditolak, pekerjaan yang berguna berlanjut, dan otoritas tambahan tidak dapat muncul tanpa grant lain yang disengaja.

Scope opsional mengubah grant, bukan tingkat kepercayaan pada client

Scope yang ditolak menguji client sama seperti authorization server

Consent opsional tidak menutup bagian lain dari batas OAuth atau agent

Sumber

Ikuti artikel Berita AI terbaru

Lanjut membaca

AI Gateway User Insights Menandai Anomali Pengeluaran—Bukan Menghentikannya

Model Hardware Standard Anthropic adalah Antarmuka, Bukan Sertifikasi Keselamatan

Laporan Risiko Anthropic Agustus Adalah Pengungkapan, Bukan Sertifikat Keamanan