Cloudflare OAuth untuk Semua Pelanggan
(blog.cloudflare.com)- Cloudflare memungkinkan pelanggan membuat aplikasi self-managed OAuth sendiri, sehingga akses ke Cloudflare API dapat disediakan melalui alur otorisasi terdelegasi standar
- Sebelumnya, hanya sebagian partner yang di-onboarding secara manual yang dapat menggunakan OAuth pihak ketiga, sementara pengembang integrasi mandiri harus bergantung pada API token yang tidak cocok untuk alur aplikasi terdelegasi
- Untuk peluncuran publik penuh, Cloudflare meningkatkan layar persetujuan, pencabutan, dan tampilan kepemilikan aplikasi, serta melakukan upgrade bertahap mesin OAuth Hydra dari 1.X ke 2.X
- Selama proses upgrade, terjadi migrasi skema, error pembaruan token, risiko hilangnya event pencabutan, dan peningkatan 403; hal ini ditangani dengan pembuatan indeks konkuren, antrean replay pencabutan, dan pemulihan data
- Setelah upgrade, P95 API turun 45% dari 185 ms menjadi 101 ms, dan penggunaan CPU juga turun dari 1,07 core menjadi 0,67 core, sehingga fondasi operasional OAuth publik menjadi stabil
Perluasan Cakupan Publik Cloudflare OAuth
- Cloudflare selama ini memungkinkan pembuatan otomasi, CI/CD, dan integrasi infrastruktur melalui platform API, dan kini membuka self-managed OAuth untuk semua pelanggan
- Cloudflare OAuth sendiri bukan fitur baru; fitur ini sudah digunakan dalam integrasi partner seperti Wrangler atau PlanetScale
- Namun, OAuth pihak ketiga yang ada sebelumnya hanya tersedia untuk sejumlah kecil integrasi yang di-onboarding secara manual, sehingga belum terbuka bagi ekosistem pengembang yang lebih luas
- Pengembang yang membuat integrasi sendiri harus bergantung pada API token, dan pendekatan ini sulit dikelola serta tidak cocok dengan banyak alur aplikasi terdelegasi
- Dengan self-managed OAuth, pengembang dapat menyediakan alur OAuth standar, tempat pelanggan menyetujui langsung akses dengan cakupan tertentu
- Use case utamanya adalah integrasi SaaS, platform pengembang internal, dan alat agen
- Pengguna mendapatkan persetujuan yang lebih jelas, pencabutan yang mudah, dan kontrol lebih besar atas izin aplikasi
Pembenahan Fondasi Keamanan untuk Peluncuran Publik Penuh
- Solusi OAuth awal cukup untuk sejumlah kecil partner terkelola, tetapi model izin, pengalaman persetujuan, dan cara mitigasi penyalahgunaannya belum cukup matang untuk dibuka ke semua pelanggan
- Awal tahun ini, Cloudflare meningkatkan pengalaman persetujuan agar lebih jelas menampilkan aplikasi mana yang meminta akses dan izin apa yang akan diterima
- Di dashboard, Cloudflare menambahkan fitur pencabutan agar pengembang dapat dengan mudah mengontrol aplikasi mana yang dapat mengakses data
- Untuk mengurangi serangan phishing OAuth, kepemilikan aplikasi juga dibuat lebih terlihat
- Untuk membuka self-managed OAuth bagi semua pelanggan, diperlukan upgrade mesin OAuth yang menjaga stabilitas data dan keamanan sambil meminimalkan gangguan pengguna
Persiapan Upgrade Hydra 1.X
- Cloudflare sudah lama menggunakan mesin OAuth open source Hydra sebagai mesin internal Cloudflare OAuth
- Seiring pertumbuhan platform pengembang dan meningkatnya workflow agen, dibutuhkan upgrade besar untuk fitur baru dan peningkatan performa
- Alih-alih melakukan upgrade besar sekaligus, Cloudflare memilih pendekatan bertahap: pindah terlebih dahulu ke rilis 1.X terbaru, lalu mengevaluasi perubahan perilaku dan performa sebelum beralih ke upgrade 2.X
- Upgrade 1.X saja sudah berpotensi berdampak pada pelanggan
- Database Hydra membuat indeks dengan cara mengambil exclusive lock pada tabel penting
- Menambahkan kolom ke tabel penting dan memindahkan kolom lain ke tabel baru
- SDK dari versi Hydra yang digunakan menjalankan
SELECT *, yang dapat menimbulkan masalah deserialisasi saat skema berubah
- Untuk mencegah dampak pada pengguna, migrasi SQL ditulis ulang dengan cara seperti
CREATE INDEX CONCURRENTLY, dan Cloudflare membuat versi Hydra kustom yang memilih kolom eksplisit alih-alihSELECT *
Strategi Upgrade Hydra 2.X
- Karena perubahan skema pada upgrade 2.X sangat besar, upgrade in-place tidak cocok, sehingga Cloudflare memilih strategi blue-green
- Sekadar mengalihkan switch ke versi baru tidaklah cukup
- Upgrade dan migrasi memakan waktu beberapa jam
- Selama waktu itu, sistem harus tetap berfungsi dengan benar
- Opsi blue-green pertama adalah memblokir penulisan database sehingga otorisasi baru dihentikan
- Penulisan baru selama transisi tidak akan hilang
- Pengguna yang belum memiliki kredensial valid tidak dapat menggunakan aplikasi OAuth yang ada
- Selama upgrade, pengguna tidak dapat mencabut akses aplikasi
- Strategi akhir adalah tetap mempertahankan penulisan database, tetapi menerima kemungkinan hilangnya sebagian penulisan dan mengurangi risikonya
- Masa kedaluwarsa token diperpanjang menjadi beberapa jam untuk mengurangi penulisan token baru
- Aplikasi yang menerima token sebelum upgrade dapat terus digunakan tanpa melakukan refresh baru
- Hilangnya event pencabutan dicegah dengan sistem antrean berbasis Cloudflare Queues
- Saat event pencabutan terjadi, informasinya dicatat ke antrean
- Setelah beralih ke database versi green, antrean dikosongkan untuk me-replay pencabutan selama jendela upgrade
- Jika pemrosesan ini gagal, akses aplikasi yang telah dicabut oleh pengguna dapat secara tidak sengaja dipulihkan
Upgrade 1.X dan Masalah Refresh Token
- Upgrade pertama ke rilis 1.X terbaru berjalan tanpa masalah besar dari sisi operasional
- Migrasi database kustom berjalan lebih cepat dari perkiraan dan tidak berdampak pada pengguna
- Karena versi lama tidak dapat melakukan introspection terhadap token yang dibuat versi baru, diperlukan hard cutover
- Setelah cutover, error refresh token yang sebelumnya tidak terlihat meningkat
- Penyebabnya adalah perilaku invalidasi refresh yang lebih ketat pada versi baru
- Jika refresh token digunakan ulang, Hydra membatalkan seluruh rantai access token dan refresh token
- Wrangler dan klien MCP memiliki volume request tinggi, sehingga satu penggunaan ulang refresh token dapat membatalkan seluruh sesi
- Cloudflare menambahkan perilaku refresh token coalescing pada Worker yang merutekan traffic OAuth ke tujuan yang benar
- Request refresh token di-cache sebentar sebelum mencapai Hydra
- Jika retry terdeteksi, request diproses singkat dan dibalas tanpa membatalkan token
- Hydra 2.X memiliki
refresh token grace periodyang dapat dikonfigurasi, yang mengizinkan retry refresh token selama periode tertentu tanpa membatalkan seluruh rantai
Transisi 2.X dan Proses Pemulihan
- Cloudflare menjalankan upgrade blue-green karena tidak dapat menerima downtime beberapa jam yang berdampak besar pada pengguna
- Transisi aktual membutuhkan lebih banyak pekerjaan daripada sekadar menyalin database dan men-deploy Hydra baru
- Mengaktifkan antrean penangkapan replay pencabutan
- Menyalin database dan memulihkannya ke target baru
- Membersihkan data lama yang melanggar constraint versi baru
- Cutover serentak layanan Hydra dan dua sistem internal inti
- Monitoring dan verifikasi setelah cutover
- Jendela upgrade dipilih pada waktu ketika jumlah request per detik Hydra paling rendah untuk meminimalkan hilangnya penulisan token
- Migrasi produksi berjalan baik di database baru selain beberapa tuning timeout, dengan waktu eksekusi murni sekitar 3 jam
- Segera setelah pengalihan traffic, pekerjaan pembersihan data pada authorization service mulai menghapus data OAuth policy secara berlebihan
- Layanan tersebut bergantung pada Hydra consent session API
- Salah satu migrasi Hydra merusak sebagian status sesi OAuth yang valid, sehingga sesi valid ditandai sebagai tidak valid
- Ketidaksesuaian antara Hydra dan authorization service muncul sebagai peningkatan 403
- Cloudflare memitigasinya dengan pemulihan data, dan mulai memperbaiki perilaku OAuth authorization untuk mengurangi ketergantungan pada data policy statis
- Beberapa perbaikan kecil dari perilaku khusus klien lainnya juga segera diterapkan
Peningkatan Performa Setelah Upgrade
- Setelah upgrade versi Hydra selesai, traffic OAuth tetap stabil, dan performa serta keandalan sistem untuk pelanggan meningkat
- Fondasi baru ini sama dengan fondasi API OAuth baru yang sudah divalidasi di staging, dan memungkinkan rilis self-managed OAuth pada 3 Juni
- Angka utama yang diamati selama migrasi database:
- Baris yang diperbarui: 132,5 juta
- Baris yang disisipkan: 114,7 juta
- Byte sementara: 136,97 GB
- Commit transaksi: 22,2 ribu
- Metrik performa rata-rata Hydra secara umum membaik setelah upgrade
- API P95: 185 ms → 101 ms, turun 45%
- Memori RSS: 888 MB → 763 MB, turun 14%
- Go heap alloc: 449 MB → 271 MB, turun 40%
- Goroutines: 4015 → 3076, turun 23%
- CPU: 1,07 core → 0,67 core, turun 37%
Cara Memulai
- Saat ini semua pelanggan Cloudflare dapat membuat aplikasi OAuth sendiri dan membangun integrasi di atas Cloudflare
- Untuk memulai, lihat dokumentasi atau buat aplikasi OAuth pertama Anda di halaman OAuth apps pada dashboard
1 komentar
Pendapat di Hacker News
Saya pembuat Ory Hydra. Melihat tulisan blog dan penjelasan teknis ini benar-benar menyenangkan, dan saya tidak pernah membayangkan perangkat lunak ini akan melindungi perusahaan-perusahaan internet dunia
Senang mendengar versi 2.x berjalan baik pada skala sebesar itu, dan penggunaan CPU-nya juga terlihat sangat kecil sampai sulit dipercaya
Kalau muncul masalah, ada juga versi komersial yang lebih cepat. Jika tertarik pada OAuth internal, IAM, izin ReBAC, API key, dan keamanan agen, produk open source dan komersialnya bisa dilihat di https://github.com/ory dan https://www.ory.com/
Dulu saya menjalankan framework identity server untuk dotnet secara self-hosted dan menangani puluhan miliar request per bulan; pada skala itu, OAuth dan OpenID Connect pada dasarnya sudah mendekati masalah yang terselesaikan, dan beban pemeliharaannya juga rendah
Itu adalah layanan inti organisasi dan tuntutan compliance-nya juga kuat, tetapi tim yang menanganinya mungkin hanya sekitar 3 orang, dan sampai sekarang masih berjalan dengan baik
Saya tidak pernah paham mengapa ada begitu banyak kebingungan seputar protokol ini, dan hampir semua engineer junior yang pernah bekerja dengan saya kesulitan memahaminya. Blog Scott Brady https://www.scottbrady.io/ sangat membantu untuk topik ini
Sepertinya ketika autentikasi/otorisasi terlibat, para engineer merasakan “ketakutan” yang mendasar. Mereka terbiasa memecahkan masalah, tetapi autentikasi/otorisasi hadir seperti prasyarat untuk pemecahan masalah itu, sehingga menambah biaya kognitif
Ini Cloudflare yang khas. Berfungsi baik untuk semua orang dan tidak terlalu mahal, tetapi sebagai konsekuensi dari semua keunggulan itu, ia menjadi berada di pusat segalanya
Saya Grant. Bersama Aeneas, saya menulis sebagian besar kode migrasi 2.0. Terima kasih atas tulisan dari tim Cloudflare
Saya penasaran apakah bagian “hasil investigasi menunjukkan ada masalah pada salah satu migrasi Hydra, yang merusak status sebagian sesi OAuth yang valid, sehingga migrasi menandai sesi tersebut sebagai tidak valid” merujuk pada salah satu file migrasi open source
Saya sudah tidak terlibat dalam proyeknya, tetapi ingin tahu apakah sudah diperbaiki di upstream
Untuk konteks keseluruhan, minimal harus ikut memuat rencana alur otorisasi dan autentikasi di dalam ekosistem Cloudflare, jadi perasaan saya campur aduk. Contoh GitHub juga tidak ada
Meski begitu, benar bahwa Cloudflare memulai ke arah yang tepat, tetapi dibandingkan seluruh rangkaian produk Ory yang menjadi fondasinya, perjalanannya masih panjang. Ory Kratos menangani identitas, login, registrasi, pemulihan, autentikasi multi-faktor, dan lain-lain: https://github.com/ory
Menurut saya cakupan penuhnya juga harus mencakup penyimpanan pengguna, SAML, dan rencana model organisasi multi-tenant. Sebagai contoh bagus, Zitadel https://github.com/zitadel menyediakan UI admin untuk multi-tenancy organisasi, dukungan OIDC/PKCE, dan sebagian RBAC juga bisa ditambahkan
Supabase juga menyediakan autentikasi terkelola dan open source: https://github.com/supabase/auth
Terlepas dari “MCP sudah mati dan Skills selamanya”, saya khawatir rencana untuk memasang MCP dan merotasi key di semua ini akan segera meledak besar
Registrasi klien dinamis OAuth 2.0 (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Saya ingin mendengar pendapat, khususnya dalam konteks SaaS multi-tenant dan asisten AI tertanam
Dalam alur redirect yang biasanya dipakai saat menghubungkan MCP ke agen, spesifikasinya hampir tidak mengatakan bagaimana membuat ini aman
Kita tentu tidak ingin siapa pun bisa mendaftarkan klien dengan callback sembarang. Itu jalan menuju phishing
Jika seseorang mendaftarkan klien dengan URL callback berbahaya lalu menipu pengguna agar mengklik link yang memulai alur itu, penyedia identitas yang sah akan mengautentikasi pengguna lalu menyerahkan access token kepada penyerang
Spesifikasi membahas initial access token yang didapat klien terlebih dahulu sebelum registrasi lalu seolah melewatinya begitu saja, tetapi detailnya kurang, dan dalam situasi ketika semua end user menjadi klien, kemungkinan sulit berjalan
Idealnya, kita ingin menetapkan allowlist pola redirect agar terbatas ke tujuan seperti ChatGPT. Namun ini perilaku non-standar, sehingga vendor IAM tidak terburu-buru melakukannya
Saya tidak mengerti maksudnya di sini. Tidak ada dunia di mana ini berakhir baik. Cloudflare hampir seperti penyedia infrastruktur, dan model untuk infrastruktur yang memungkinkan pengguna mendelegasikan izin akunnya ke klien pihak ketiga punya potensi penyalahgunaan yang besar
Kalau perusahaan seperti AWS tidak melakukannya, saya rasa ada alasannya
Misalnya, IAM bisa memberi izin update Lambda kepada GitHub Actions yang berjalan dari repository tertentu
OAuth dan autentikasi enterprise mungkin salah satu hal terburuk yang pernah dibuat. Saat berurusan dengan cloud, ini bisa menjadi bagian yang paling membingungkan dan menjengkelkan
Bahkan alat AI butuh 1 tahun hanya untuk menangani OAuth dasar di sistem headless, tanpa berasumsi bahwa mereka bisa membuka browser
Kalau kita memang harus masuk ke segala macam lubang kelinci autentikasi dari penyedia cloud besar seperti RBAC/IAM/identitas workload/akun layanan, mohon sisakan cara sederhana untuk penggunaan pribadi
Cukup satu API key saja. Simpan sebagai rahasia dan cabut bila perlu; tidak perlu ada 10 ribu lapisan campur aduk autentikasi yang saling terkait di setiap lapisan setiap platform
Ini mimpi buruk privasi
Untuk API key, kami baru saja merilis Ory Talos(https://github.com/ory/talos). Ini alternatif yang bagus ketika OAuth2 terlalu berlebihan untuk use case-nya
Ada juga use case dan kekhawatiran keamanan yang membenarkan penggunaan OAuth2. Spesifikasi seperti DPoP dapat membuat alur seperti ini lebih aman
Use case yang disajikan di sini tampaknya cocok untuk OAuth2, tetapi tidak cocok untuk semua hal. Kompleksitas membuat pengamanan sistem jadi lebih sulit
Keunggulan OAuth2/OIDC adalah kepercayaan tidak ditempatkan pada pemegang API key, melainkan pada identitas nyata yang membutuhkan akses
Autentikasi itu sulit untuk autentikasi bagi banyak pengguna. Autentikasi untuk diri sendiri sangat sederhana, dan makin mudah jika memakai framework yang layak
Kalau ragu dengan implementasinya, lempar saja ke salah satu model terbaru. Mereka cukup bagus untuk menemukan masalah pada sistem autentikasi yang sesederhana itu
“Ory Enterprise License: membuka fitur kelas enterprise seperti SLA keamanan CVE, SAML, organisasi B2B, multi-tenancy, skalabilitas yang lebih baik” [0]
Atau tetap pakai Keycloak yang menyediakan produk self-hosted sepenuhnya [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
Alasan adanya versi komersial adalah pertanyaan bagaimana mendanai open source kelas dunia secara berkelanjutan. Adanya model bisnis yang berjalan untuk open source yang menopang perusahaan-perusahaan software terbesar di dunia itu bukan hal buruk, melainkan hal baik
Sebagai catatan, IBM juga menemukan cara menghasilkan uang dari Keycloak
Ini pada dasarnya membahas OAuth untuk akses akun Cloudflare, bukan fitur “login” umum yang di-host Cloudflare untuk aplikasi kustom
Saya kira saya sudah memahami apa itu OAuth, tetapi tulisan ini membingungkan. Saya menganggapnya sebagai protokol terstandar yang menyediakan key akses per klien
Di sini OAuth yang dikelola sendiri itu apa? Perlu dijelaskan akses ke apa yang diberikan, siapa kliennya, dan siapa partnernya
Ini memungkinkan Anda meng-host sendiri sistem OAuth untuk menyetujui/menolak akses ke resource Anda sendiri. Alih-alih menunggu Cloudflare mengizinkan Y dalam kondisi X, Anda bisa membuat logika yang Anda inginkan
Pada dasarnya alurnya: “login ke Cloudflare” → Cloudflare memeriksa penggunaan OAuth yang dikelola sendiri → dialihkan ke OAuth milik pengguna → Cloudflare memercayai responsnya → jika pengguna menyetujui, akses akun diizinkan