Tüm müşteriler için Cloudflare OAuth
(blog.cloudflare.com)- Cloudflare, müşterilerin doğrudan self-managed OAuth uygulamaları oluşturmasına olanak tanıyarak Cloudflare API erişimini standart yetkilendirme devri akışıyla sunabilmelerini sağlıyor
- Önceden yalnızca elle onboarding yapılan bazı iş ortakları üçüncü taraf OAuth kullanabiliyordu; kendi entegrasyonlarını geliştirenler ise delege edilmiş uygulama akışlarına uymayan API token’larına güvenmek zorundaydı
- Genel kullanıma açmak için onay ekranı, iptal, uygulama sahipliği gösterimi iyileştirildi ve OAuth motoru Hydra 1.X’ten 2.X’e kademeli olarak yükseltildi
- Yükseltme sürecinde şema migrasyonları, token yenileme hataları, iptal olaylarının kaybolma riski ve 403 artışı yaşandı; bunlara eşzamanlı indeks oluşturma, iptal yeniden oynatma kuyruğu ve veri geri yükleme ile yanıt verildi
- Yükseltmeden sonra API P95 185 ms’den 101 ms’ye düşerek %45 azaldı; CPU kullanımı da 1,07 çekirdekten 0,67 çekirdeğe geriledi ve herkese açık OAuth işletim temeli kararlı hale geldi
Cloudflare OAuth’un herkese açılma kapsamının genişletilmesi
- Cloudflare, platform API’siyle otomasyon, CI/CD ve altyapı entegrasyonları oluşturulmasını uzun süredir sağlıyordu; şimdi self-managed OAuth’u tüm müşterilere açtı
- Cloudflare OAuth’un kendisi yeni bir özellik değil; Wrangler veya PlanetScale gibi iş ortağı entegrasyonlarında zaten kullanılıyordu
- Ancak mevcut üçüncü taraf OAuth, yalnızca elle onboarding yapılan az sayıda entegrasyona sunuluyordu ve daha geniş geliştirici ekosistemine açık değildi
- Kendi entegrasyonunu oluşturan geliştiriciler API token’larına güvenmek zorundaydı; bu yöntem yönetimi zor ve birçok delege edilmiş uygulama akışıyla pek uyumlu değildi
- self-managed OAuth ile geliştiriciler, müşterilerin kapsamı belirlenmiş erişimi doğrudan onayladığı standart OAuth akışını sunabilir
- Başlıca kullanım senaryoları SaaS entegrasyonları, dahili geliştirici platformları ve ajan araçlarıdır
- Kullanıcılar daha net onay, kolay iptal ve uygulama izinleri üzerinde daha fazla kontrol elde eder
Genel kullanıma açmak için güvenlik temelinin düzenlenmesi
- İlk OAuth çözümü az sayıda yönetilen iş ortağı için yeterliydi, ancak tüm müşterilere açılmak için izin modeli, onay deneyimi ve kötüye kullanımı azaltma yöntemleri yeterince olgun değildi
- Cloudflare bu yılın başlarında onay deneyimini iyileştirerek hangi uygulamanın erişim istediğini ve hangi izinleri alacağını daha net gösterdi
- Panoya iptal özelliği eklenerek geliştiricilerin hangi uygulamaların verilerine erişebileceğini kolayca kontrol etmesi sağlandı
- OAuth oltalama saldırılarını azaltmak için uygulama sahipliği de daha görünür hale getirildi
- self-managed OAuth’u tüm müşterilere açmak için, kullanıcı kesintisini en aza indirirken veri kararlılığı ve güvenliği koruyan bir OAuth motoru yükseltmesi gerekiyordu
Hydra 1.X yükseltmesine hazırlık
- Cloudflare uzun süredir açık kaynak OAuth motoru Hydra’yı Cloudflare OAuth’un dahili motoru olarak kullanıyor
- Geliştirici platformu büyüdükçe ve ajan iş akışları arttıkça, yeni özellikler ve performans iyileştirmeleri için büyük ölçekli bir yükseltme gerekli hale geldi
- Tek seferde büyük bir yükseltme yapmak yerine önce en güncel 1.X sürümüne geçip davranış ve performans değişikliklerini değerlendirdikten sonra 2.X yükseltmesine geçilen aşamalı bir yaklaşım seçildi
- Yalnızca 1.X yükseltmesi bile müşterileri etkileyebilirdi
- Hydra veritabanı, önemli tablolarda exclusive lock alarak indeks oluşturuyordu
- Önemli tablolara sütun ekliyor, bazı sütunları ise yeni tablolara taşıyordu
- Kullanılan Hydra sürümünün SDK’sı
SELECT *çalıştırdığı için şema değiştiğinde deserialization sorunları oluşabilirdi
- Kullanıcı etkisini önlemek için SQL migrasyonları
CREATE INDEX CONCURRENTLYgibi yöntemlerle yeniden yazıldı veSELECT *yerine açıkça belirtilmiş sütunları seçen özel bir Hydra sürümü oluşturuldu
Hydra 2.X yükseltme stratejisi
- 2.X yükseltmesinde şema değişikliklerinin kapsamı büyük olduğundan in-place upgrade uygun değildi; Cloudflare blue-green stratejisini seçti
- Yalnızca yeni sürüme geçiş anahtarını çevirmek yeterli değildi
- Yükseltme ve migrasyonlar birkaç saat sürüyordu
- Bu süre boyunca sistemin doğru şekilde çalışmaya devam etmesi gerekiyordu
- İlk blue-green seçeneği, veritabanı yazmalarını engelleyerek yeni yetkilendirmeleri bloke etmekti
- Geçiş sırasında yeni yazmalar kaybolmazdı
- Halihazırda geçerli kimlik bilgileri olmayan kullanıcılar mevcut OAuth uygulamalarını kullanamazdı
- Yükseltme sırasında kullanıcılar uygulama erişimini iptal edemezdi
- Nihai strateji, veritabanı yazmalarını sürdürüp bazı yazma kayıplarını göze almak ve kayıp riskini azaltmaktı
- Yeni token yazmalarını azaltmak için token sona erme süresi birkaç saate çıkarıldı
- Yükseltmeden önce token alan uygulamalar, yeniden yenileme yapmadan kullanmaya devam edebildi
- İptal olaylarının kaybolması, Cloudflare Queues tabanlı bir kuyruk sistemiyle engellendi
- Bir iptal olayı gerçekleştiğinde ilgili bilgi kuyruğa yazıldı
- green sürüm veritabanına geçildikten sonra kuyruk boşaltılarak yükseltme penceresi sırasındaki iptaller yeniden oynatıldı
- Bu işlem başarısız olsaydı, kullanıcının iptal ettiği uygulamanın erişimi istemeden geri yüklenebilirdi
1.X yükseltmesi ve token yenileme sorunu
- En güncel 1.X sürümüne yapılan ilk yükseltme, operasyon açısından büyük bir sorun olmadan ilerledi
- Özel veritabanı migrasyonları beklenenden hızlı çalıştı ve kullanıcı etkisi olmadı
- Eski sürüm, yeni sürümde oluşturulan token’ları introspection yapamadığı için hard cutover gerekti
- Cutover sonrasında daha önce görünmeyen refresh token hataları arttı
- Bunun nedeni yeni sürümün daha katı refresh invalidation davranışıydı
- Refresh token yeniden kullanıldığında Hydra tüm access token ve refresh token zincirini geçersiz kılıyordu
- Wrangler ve MCP istemcilerinde istek hacmi yüksek olduğundan, tek bir refresh token yeniden kullanımı tüm oturumun geçersiz kılınmasına yol açabiliyordu
- Cloudflare, OAuth trafiğini doğru hedefe yönlendiren Worker’a refresh token coalescing davranışı ekledi
- Refresh token istekleri Hydra’ya ulaşmadan önce kısa süreliğine önbelleğe alındı
- Yeniden deneme algılandığında token geçersiz kılınmadan istek kısa yoldan işlenip yanıtlandı
- Hydra 2.X’te, tüm zinciri geçersiz kılmadan belirli bir süre refresh token yeniden denemelerine izin veren yapılandırılabilir bir
refresh token grace periodbulunuyor
2.X geçişi ve kurtarma süreci
- Cloudflare, kullanıcı etkisi yüksek birkaç saatlik kesintiyi kabul edemediği için blue-green yükseltmesini yürüttü
- Gerçek geçiş, basit bir veritabanı kopyalama ve yeni Hydra dağıtımından daha fazla iş gerektirdi
- İptal yeniden oynatma yakalama kuyruğunun etkinleştirilmesi
- Veritabanının kopyalanması ve yeni hedefe geri yüklenmesi
- Yeni sürümün kısıtlarını ihlal eden mevcut verilerin temizlenmesi
- Hydra servisi ve iki kritik dahili sistemin eşzamanlı cutover’ı
- Cutover sonrası izleme ve doğrulama
- Yükseltme penceresi, token yazma kaybını en aza indirmek için Hydra’nın saniye başına istek sayısının en düşük olduğu zamana seçildi
- Prodüksiyon migrasyonu, bazı timeout ayarları dışında yeni veritabanında iyi çalıştı ve saf çalışma süresi yaklaşık 3 saat oldu
- Trafik geçişinin hemen ardından authorization service’in veri temizleme işinin OAuth policy verilerini aşırı sildiği görüldü
- Bu servis Hydra consent session API’sine dayanıyor
- Hydra migrasyonlarından biri, bazı geçerli OAuth oturum durumlarını bozarak geçerli oturumları geçersiz olarak işaretledi
- Hydra ile authorization service arasındaki tutarsızlık 403 artışı olarak ortaya çıktı
- Cloudflare veri geri yükleme ile etkiyi azalttı ve statik policy verilerine bağımlılığı azaltmak için OAuth authorization davranışını iyileştirme çalışmalarına başladı
- Bunun dışında bazı istemciye özel davranışlardan kaynaklanan küçük düzeltmeler de hızla uygulandı
Yükseltme sonrası performans iyileştirmeleri
- Hydra sürüm yükseltmesi tamamlandıktan sonra OAuth trafiği kararlı kaldı ve müşteriler için sistem performansı ile güvenilirliği iyileşti
- Yeni temel, staging’de zaten doğrulanmış yeni OAuth API’leriyle aynı altyapı; 3 Haziran’daki self-managed OAuth sürümünü mümkün kıldı
- Veritabanı migrasyonu sırasında gözlemlenen başlıca sayılar:
- Güncellenen satırlar: 132,5M
- Eklenen satırlar: 114,7M
- Geçici bayt: 136,97 GB
- Transaction commit: 22,2k
- Hydra’nın ortalama performans metrikleri yükseltme sonrasında genel olarak iyileşti
- API P95: 185 ms → 101 ms, %45 azalma
- RSS bellek: 888 MB → 763 MB, %14 azalma
- Go heap alloc: 449 MB → 271 MB, %40 azalma
- Goroutine’ler: 4015 → 3076, %23 azalma
- CPU: 1,07 çekirdek → 0,67 çekirdek, %37 azalma
Nasıl başlanır
- Şu anda tüm Cloudflare müşterileri kendi OAuth uygulamalarını oluşturup Cloudflare üzerinde entegrasyonlar inşa edebilir
- Başlamak için dokümantasyona bakabilir veya panodaki OAuth apps sayfasından ilk OAuth uygulamanızı oluşturabilirsiniz
1 yorum
Hacker News yorumları
Ory Hydra’yı yapan kişiyim. Bu blog yazısını ve teknik açıklamayı görmek gerçekten sevindirici; bu yazılımın dünyanın internet şirketlerini koruyacağını hiç hayal etmemiştim.
2.x sürümünün bu ölçekte iyi çalıştığını görmek güzel ve CPU kullanımı da inanılmaz derecede düşük görünüyor.
Bir sorun çıkarsa daha hızlı ticari bir sürüm de var. Kendi OAuth, IAM, ReBAC yetkilendirmesi, API anahtarları ve ajan güvenliğiyle ilgileniyorsanız açık kaynak ve ticari ürünleri https://github.com/ory ve https://www.ory.com/ adreslerinde görebilirsiniz.
Geçmişte dotnet için identity server framework’ünü self-hosted olarak çalıştırıp ayda milyarlarca isteği işledim; o ölçekte OAuth ve OpenID Connect pratikte neredeyse çözülmüş bir problem ve bakım yükü de düşüktü.
Kurumun kritik bir servisiydi ve compliance gereksinimleri de yüksekti, ama sorumlu ekip muhtemelen 3 kişiydi ve hâlâ sorunsuz çalışıyor.
Bu protokoller konusunda neden bu kadar çok kafa karışıklığı olduğunu anlayamıyordum; birlikte çalıştığım junior mühendislerin neredeyse hepsi anlamakta zorlanıyordu. Scott Brady’nin blogu https://www.scottbrady.io/ bu konuda çok yardımcı oluyor.
Kimlik doğrulama/yetkilendirme devreye girince mühendislerde ilkel bir “korku” oluşuyor gibi. Problem çözmeye alışıklar ama kimlik doğrulama/yetkilendirme, sanki o problem çözmenin önkoşulu gibi araya girip bilişsel yük yaratıyor.
Tipik Cloudflare. Herkes için iyi çalışıyor ve o kadar da pahalı değil, ama tüm bu avantajların sonucu olarak her şeyin merkezi haline geliyor.
Ben Grant. Aeneas ile birlikte 2.0 migration kodunun büyük kısmını yazdım. Cloudflare ekibinin yazısı için teşekkürler.
“İncelememiz sırasında, Hydra migration’larından birinde bir sorun olduğunu ve bunun bazı geçerli OAuth oturumlarının durumunu bozduğunu, sonuç olarak migration’ın bu oturumları geçersiz olarak işaretlediğini tespit ettik” kısmının açık kaynak migration dosyalarından biri olup olmadığını merak ediyorum.
Artık projede yer almıyorum ama upstream’de düzeltilip düzeltilmediğini bilmek isterim.
Genel bağlamın, en azından Cloudflare ekosistemi içinde, yetkilendirme ve kimlik doğrulama akışları için bir plan da içermesi gerekiyor; bu yüzden duygularım karışık. GitHub örneği bile yok.
Yine de Cloudflare’ın doğru yönde başladığı doğru, ama temelindeki Ory ürün ailesinin tamamıyla karşılaştırınca gidecek daha çok yolu var. Ory Kratos; kimlik, giriş, kayıt, kurtarma, çok faktörlü kimlik doğrulama ve benzerlerini ele alıyor: https://github.com/ory
Bana göre tam kapsam; kullanıcı deposu, SAML ve çok kiracılı organizasyon modeli planlarını da içermeli. İyi bir örnek olarak Zitadel https://github.com/zitadel organizasyonel multi-tenancy için yönetim arayüzü, OIDC/PKCE desteği vb. sunuyor ve bir miktar RBAC da eklenebiliyor.
Supabase de managed ve açık kaynak kimlik doğrulama sunuyor: https://github.com/supabase/auth
“MCP öldü, Skills sonsuza kadar yaşayacak” tartışmasını bir kenara bırakırsak, bunların hepsinde MCP ekleme ve anahtar döndürme planlarının yakında büyük sorun çıkaracağından endişeliyim.
OAuth 2.0 dynamic client registration (RFC 7591): https://datatracker.ietf.org/doc/html/rfc7591
https://modelcontextprotocol.io/specification/2025-03-26/bas...
Özellikle çok kiracılı SaaS ve gömülü yapay zeka asistanı bağlamında görüş duymak isterim.
MCP’yi bir ajana bağlarken genelde kullanılan redirect flow için spesifikasyon bunun nasıl güvenli hale getirileceği konusunda neredeyse hiçbir şey söylemiyor.
Herhangi birinin rastgele bir callback ile istemci kaydetmesine izin vermek istemezsiniz. Bu, phishing’e açık bir yol oluşturur.
Kötü niyetli bir callback URL’siyle bir istemci kaydedip sonra kullanıcıyı o akışı başlatan bir bağlantıya tıklamaya ikna ederseniz, meşru kimlik sağlayıcı kullanıcıyı doğruladıktan sonra erişim token’ını saldırgana teslim etmiş olur.
Spesifikasyon, istemcinin kayıt öncesinde aldığı bir initial access token’dan söz edip geçiyor, ancak ayrıntılar yetersiz ve her son kullanıcının istemci olduğu bir durumda muhtemelen iyi işlemez.
İdeal olarak, ChatGPT gibi hedeflerle sınırlamak için redirect pattern allowlist’i tanımlamak isterdim. Ama bu standart dışı bir davranış olduğu için IAM vendor’ları acele etmiyor.
Buradaki amacın ne olduğunu anlamıyorum. Bunun iyi biteceği bir dünya yok. Cloudflare neredeyse bir altyapı sağlayıcısı ve herhangi bir kullanıcının hesap yetkilerini üçüncü taraf bir istemciye devretmesine imkân veren bir altyapı modeli istismar potansiyeli taşıyor.
AWS gibi bir şirket bunu yapmıyorsa, bence bunun bir sebebi vardır.
Örneğin IAM, belirli bir depodan çalışan GitHub Actions’a Lambda güncelleme yetkisi verebiliyor.
OAuth ve kurumsal kimlik doğrulama, icat edilmiş en kötü şeylerden biri olabilir. Bulutla uğraşırken en kafa karıştırıcı ve sinir bozucu kısım olabilir
Yapay zeka araçlarının da tarayıcı açabileceğini varsaymadan, headless sistemlerde temel OAuth’u ele almak bile 1 yıl sürdü
RBAC/IAM/iş yükü kimliği/service account gibi büyük bulut sağlayıcılarının türlü türlü kimlik doğrulama tavşan deliklerine ineceksek, kişisel kullanım için lütfen basit bir yol da kalsın
Sadece bir API anahtarı yeter. Gizli tutar ve gerekirse iptal edersin; her platformun her katmanında 10 bin kat kimlik doğrulama ıvır zıvırının birbirine dolanmasına gerek yok
Tam bir gizlilik kâbusu
API anahtarları için Ory Talos’u (https://github.com/ory/talos) yeni çıkardık. OAuth2’nin kullanım senaryosuna göre fazla kaçtığı durumlar için iyi bir alternatif
OAuth2 kullanımını haklı çıkaran kullanım senaryoları ve güvenlik kaygıları da var. DPoP gibi spesifikasyonlar bu akışları daha güvenli hale getirebilir
Burada sunulan kullanım senaryosu OAuth2 için uygun görünüyor, ama her yere uymaz. Karmaşıklık, sistem güvenliğini daha zor hale getiriyor
OAuth2/OIDC’nin avantajı, güveni API anahtarını elinde tutana değil, erişime ihtiyaç duyan gerçek kimliğe dayandırmasıdır
Kimlik doğrulamanın zor olması, çok sayıda kullanıcı için kimlik doğrulama söz konusu olduğunda geçerli. Kendiniz için kimlik doğrulama çok basit ve düzgün bir framework kullanırsanız daha da kolay olur
Uygulamadan emin değilseniz güncel modellerden birine atın gitsin. Bu kadar basit kimlik doğrulama sistemlerindeki sorunları bulmakta epey iyiler
“Ory Enterprise License: CVE güvenlik SLA’si, SAML, B2B organizasyonlar, çoklu kiracılık, daha iyi ölçeklenebilirlik gibi enterprise özelliklerin kilidini açar” [0]
Ya da tam self-hosted ürün sunan Keycloak kullanmaya devam edebilirsiniz [1]
[0]https://github.com/ory
[1]https://www.keycloak.org/
Ticari sürümün olmasının sebebi, dünya çapında bir açık kaynağı finansal olarak nasıl sürdüreceğiniz sorusu. Gezegendeki en büyük yazılım şirketlerini ayakta tutan açık kaynak için çalışan bir iş modeli olması kötü değil, iyi bir şey
Bu arada IBM de Keycloak’tan para kazanmanın yolunu buldu
Bu temel olarak Cloudflare hesap erişimi için OAuth meselesi; kullanıcıya ait özel uygulamalar için Cloudflare tarafından barındırılan genel bir “giriş yap” türü özellik değil
OAuth’un ne olduğunu anladığımı sanıyordum ama bu yazı kafamı karıştırdı. Bunu, istemci bazlı erişim anahtarları sağlayan standartlaştırılmış bir protokol olarak görüyordum
Buradaki self-serve OAuth tam olarak nedir? Neye erişim izni veriliyor, istemci kim, partner kim; buna dair açıklama gerekiyor
Kendi kaynaklarınıza erişimi onaylayan/reddeden OAuth sistemini kendiniz host etmenize izin veriyor. Cloudflare’ın X koşulunda Y’ye izin vermesini beklemek yerine istediğiniz mantığı kurabiliyorsunuz
Özünde akış şöyle: “Cloudflare ile giriş yap” → Cloudflare, self-serve OAuth kullanımını kontrol eder → kullanıcının OAuth’una yönlendirir → Cloudflare yanıtı güvenir → kullanıcı onaylarsa hesap erişimine izin verilir