Cloudflare, Claude ile OAuth geliştirdi ve tüm prompt’ları yayımladı
(github.com/cloudflare)- Cloudflare, Cloudflare Workers için bir TypeScript kütüphanesi olarak OAuth 2.1 sağlayıcı framework’ünü duyurdu
- Uygulamanın büyük bölümü Anthropic’in Claude LLM’i kullanılarak yazıldı ve Cloudflare güvenlik mühendisleri tarafından titizlikle gözden geçirildi
- Bu kütüphane, API endpoint’leri için kimlik doğrulamayı otomatikleştirme ve token yönetimini otomatik olarak işleme olanağı sunuyor
- En güncel OAuth standartları ve PKCE, dinamik istemci kaydı, erişim kapsamı ayarları gibi temel özellikleri destekliyor
- Kritik bölümlerde uçtan uca şifreleme ve tek kullanımlık refresh token’lar gibi güvenlik tasarımını öne çıkarıyor
Cloudflare Workers için OAuth 2.1 sağlayıcı framework’ünün tanıtımı ve önemi
Bu açık kaynak proje, Cloudflare Workers ortamında kolayca bir OAuth 2.1 kimlik doğrulama sunucusu uygulayabilmek için tasarlanmış bir TypeScript kütüphanesidir.
Benzer projelerle karşılaştırıldığında, Cloudflare platformuna özel ölçeklenebilirlik ve sorunsuz entegrasyon ile güvenlik odaklı tasarım açısından güçlüdür.
Odak noktaları arasında algoritmalar, protokol standartlarına uyum (RFC-8414, RFC-7591 vb.) ve kütüphane yapısının açıklığı yer alıyor.
Özellikle token’ların ve kritik secret değerlerinin hash’lenerek saklanması, props verilerinin uçtan uca şifrelenmesi gibi ayrıntılar güvenlik için özenle tasarlanmış.
Ayrıca, kütüphane çekirdek kodunun ve dokümantasyonun büyük kısmının Claude LLM iş birliğiyle yazılmış olması da ilgi çekici bir geliştirme örneği sunuyor.
Başlıca özellikler ve avantajlar
- Worker kodunu OAuthProvider ile sarmalayarak API endpoint’lerine kimlik doğrulama özelliğini otomatik olarak ekler
- Token yönetimi (oluşturma, saklama, doğrulama, iptal etme vb.) otomatik olarak işlenir, elle uygulama gerektirmez
- Kullanıcılar fetch handler içinde kimliği doğrulanmış kullanıcı bilgisini doğrudan parametre olarak alıp kullanabilir
- Kullanıcı yönetimi, kimlik doğrulama ve UI uygulama biçimi konusunda kısıtlama yoktur (geliştirici istediği yapı ve framework’ü seçebilir)
- Kütüphanenin deposunda yalnızca hash bilgileri saklanır; secret anahtarlar gibi değerlerin kendisi tutulmaz
Kullanımın temel noktaları
- OAuthProvider örneği Worker entrypoint olarak dışa aktarılıp fetch handler görevi görebilir
- apiRoute ve apiHandler seçenekleriyle kimlik doğrulama gerektiren API endpoint alanı ile gerçek handler ayrı ayrı tanımlanır
- authorizeEndpoint, tokenEndpoint, clientRegistrationEndpoint gibi standart OAuth endpoint yolları tanımlanabilir
- Gerekirse scope ya da public client registration gibi politikalar daha ayrıntılı biçimde özelleştirilebilir
- defaultHandler ile API dışı istekler ve kimlik doğrulaması başarısız istekler de esnek biçimde ele alınabilir
Yardımcı nesneler ve API
- Fetch handler içinde
env.OAUTH_PROVIDERkullanılarak OAuth ile ilgili istekleri ayrıştırma, istemci bilgisini sorgulama ve onay tamamlama gibi işlemler yapılabilir - API istek işlemede access token geçerliyse, yetkilendirilmiş durumdaki kullanıcıya ait props bilgilerine
ctx.propsüzerinden doğrudan erişilebilir - İstemci kaydı, yetki (authorization grant) listeleri, belirli bir kullanıcı için grant görüntüleme ve iptal etme gibi işlemler de resmi API olarak sunuluyor
Token Exchange Callback
- Token verme ve yenileme sırasında props değerlerini dinamik olarak güncelleyebilen bir callback (
tokenExchangeCallback) destekleniyor - OAuth istemcisiyle bağlantılı ek token değişimi (upstream token exchange) gibi daha karmaşık senaryolar da desteklenebiliyor
- Callback içinde
accessTokenProps,newProps,accessTokenTTLgibi değerler döndürülerek özelleştirilmiş davranış uygulanabiliyor accessTokenTTLözelleştirmesi sayesinde üst OAuth sistemiyle token sona erme zamanlaması eşleştirilebiliyor- Props içinde hassas bilgiler bulunabileceği için bu değerlerin tamamı uçtan uca şifrelenerek saklanıyor
Özel hata yanıtları
- onError seçeneğiyle hata oluştuğunda bildirim gönderme, özel loglama gibi dış aksiyonlar alınabilir
- Doğrudan bir Response döndürülürse, OAuthProvider’ın kullanıcıya verdiği hata yanıtı istenen biçimde override edilebilir
Güvenlikle ilgili ayrıntılı tasarım
Uçtan uca şifreleme
- Token ile ilgili veriler ve secret’lar yalnızca hash olarak saklanır; grant props bilgileri ise token’ın kendisiyle şifrelenerek depolanır, böylece sızıntı durumlarına karşı dayanıklılık artar
userId,metadatagibi alanlar denetim (audit) ve iptal amaçlı kayıt için şifrelenmez; gerekirse geliştirici ek şifreleme uygulayabilir
Tek kullanımlık refresh token tasarımı
- OAuth 2.1’in gerektirdiği "client binding veya tek kullanım" koşulunda, bu kütüphane en fazla 2 paralel refresh token’a izin veren bir orta yol tasarımı kullanıyor
- Böylece ağ arızası gibi durumlarda yeni token’ın kaydedilmesi başarısız olsa bile eski token bir kez daha kullanılabiliyor
Claude tabanlı geliştirme süreci
- Bu kütüphane ile dokümantasyonun büyük kısmı Anthropic Claude LLM kullanılarak taslaklandı; ardından Cloudflare mühendisleri RFC’ler ve güvenlik standartlarına göre titiz bir inceleme yaptı
- Başlangıçta AI ile kod üretimine şüpheyle yaklaşılsa da, gerçek kalite ve üretkenlik artışı deneyimiyle bu bakış açısı değişti
- Geliştirme akışı, Claude için kullanılan prompt’lar ve kod iyileştirme sürecinin tamamı Git commit geçmişinde şeffaf biçimde yayımlandı
Diğer noktalar
- Workers KV namespace (
OAUTH_KV) binding’inin zorunlu olarak uygulanması gerekiyor;storage-schema.mddosyasına bakılabilir - Tüm API ve yardımcılar için
OAuthHelpersarayüzü tanımına başvurulabilir - Kütüphane şu anda beta/pre-release aşamasında ve ileride API değişiklikleri olabilir
1 yorum
Hacker News görüşleri
README'den alıntı tanıtılıyor. Bu kütüphane (ve şema belgeleri) büyük ölçüde Anthropic'in yapay zeka modeli Claude'un yardımıyla yazıldı. Cloudflare mühendisleri her şeyi titizlikle gözden geçirdi, güvenlik ve standartlara uygunluğa dikkat etti. İlk çıktılarda bile çok sayıda iyileştirme yapıldı; süreç esas olarak Claude'a ek promptlar verip sonuçları yinelemeli olarak inceleyerek ilerledi. Commit geçmişinden Claude'a nasıl prompt verildiğini ve hangi kodun üretildiğini doğrudan görmek mümkün. Başlangıçta geleneksel şüpheci duruş, “LLM'lerin bir kimlik doğrulama kütüphanesi yazmasına izin verilmemeli” yönündeydi. 2025 Ocak ayı itibarıyla ben de yapay zekaya çok şüpheyle yaklaşıyordum; LLM'lerin sadece “gösterişli bir Markov zinciri üreticisi” olduğunu, özgünlük ya da gerçek kod üretemeyeceğini düşünüyordum. Projeye eğlence olsun diye başladım ama beklediğimden iyi kod çıkınca şaşırdım. Kusursuz değildi ama yapay zekadan düzeltme isteyince çoğunu düzgün şekilde düzeltiyordu. Her satırı çeşitli RFC'lerle karşılaştırarak ve güvenlik uzmanlarıyla birlikte inceledik. Kendi şüpheciliğimi sınamaya çalıştım ama sonuçta haksız olduğumu kanıtlamış oldum. Bu süreci görmek için özellikle ilk commit'ler olmak üzere commit geçmişine bakmaya değer
Usta bir mühendisin doğru şekilde prompt vermesi durumunda, LLM'lerin bu düzeyde kod üretebilmesini beklerim. OAuth yeni bir teknoloji değil; zaten sayısız açık kaynak örneği ve farklı dillerde uygulanmış vaka eğitim verisi olarak kullanılmış olmalı. Ancak LLM'lerin tamamen yeni araştırma, malzeme bilimi, ekonomi ya da icat alanlarında devrimsel katkı sağlayacağı iddiasına hâlâ şüpheyle bakıyorum. Bunlar gerçekten “gerçek zamanlı öğrenme yeteneği” gerektiren alanlar; mevcut LLM'ler ise bugüne kadar yalnızca zaten bildikleri eski bilgilere dayanarak yetenek gösterdi. Anlamlı başarılar çoğu zaman çok sınırlı ortamlardaki cherry-pick örneklerinden ibaret. Yetenekli bir mühendis varsa geçmiş verilere dayanarak yeni kod üretilebilmesi elbette mümkün, ama LLM kullanımının getirdiği çevresel ve toplumsal yükün gerçek verimlilik kazanımına kıyasla aşırı olup olmadığı konusunda hâlâ şüpheliyim
“2025 Ocak ayına kadar ben de (@kentonv) ile aynı düşünüyordum” ifadesi kafamı karıştırdı. Çünkü kentonv başka bir kullanıcı. Bunun yazarın yan hesabı mı, yoksa yazım hatası ya da yanlış anlama mı olduğunu merak ettim. Düzenleme: Yazının büyük kısmının README alıntısı olduğunu fark ettim. > ve * işaretleriyle alıntılar daha net gösterilseydi kafa karışıklığı daha az olurdu diye düşünüyorum. kentonv profili bağlantısı eklendi
"LLM'leri gösterişli bir Markov zinciri üreticisi olarak görüyordum" ile "AI'ın oldukça iyi kod üretmesine şaşırdım" görüşleri birbiriyle çelişmiyor. LLM'leri çok faydalı buluyorum ama özünde hâlâ bir örüntü üreticisine yakınlar. Önemli nokta, bunun zaten yeterli olması ve insanların da çok farklı bir yapıya sahip olmayabileceği
Bu günlerde AI yanlısı olmaktan ziyade daha şüpheci bir konumdayım ama yine de iş akışına yapay zekayı katmayı denemeyi sürdürüyorum. Pratikte bir şeyi açıklamak daha zor olduğu için çoğu zaman doğrudan kendim yapmak daha kolay geliyor. Çok eğlenceli de değil, ama bunun “geleceğin” aracı olduğunu düşündüğüm için öğrenmenin akıllıca olacağına inanıyorum. Şimdilik gerçek AI tooling'in hâlâ çok erken aşamada olduğunu düşünüyorum. İleride ilginç UX örnekleri çıkmasını merakla bekliyorum
Başlarda Claude'a nasıl prompt verildiğini ve gerçek kodu nasıl ürettiğini görmek için commit geçmişine doğrudan bakılması öneriliyor. İlk commit sayfası bağlantısı verilmiş. Açık ve somut talimatlar çoktu; örnek commit 1, örnek commit 2 gibi örneklere de bakılabilir
Cloudflare workers-oauth-provider commit'leri arasındaki sorunlu commit'ten alıntı. Claude önceki commit'te bir bug üretmiş, bunu çok sayıda promptla düzeltmeye çalışmışlar ama sürekli başarısız olmuş. Sonunda insan doğrudan düzeltmiş ve hatta README'ye OAuth 2.1 spesifikasyonuyla ilgili sorunu da belgelemiş. Bu deneyim bana da yapay zeka kullanımında çok tanıdık geliyor. Çoğu zaman yarıya kadar çok iyi gidip geri kalanında zorlandığını görüyorum
AI'ın belli bir noktaya kadar iyi gidip bir hata yaptığında sonrasını tamamen bozmasına dikkat çekiliyor. Bir hata tespit edildiğinde hemen konuşmanın başına dönüp promptu baştan yazmak gerekiyor. Bir kez hata yaptıktan sonra ne kadar düzeltmeye çalışsanız da sonuçlar yanlış gelmeye devam ediyor. Bu yüzden doğru başlangıç mesajında her şeyi açıkça belirterek en baştan yeniden üretmek, aynı hatayı tekrar etmemesi için daha etkili oluyor
Bu sorunu hafifletmek için testler ya da net bir spec hazırlayıp AI'ın bunu çözmesini istemek yardımcı oluyor. Birkaç ay öncesine kadar AI bu tür spec bulmacalarını çözmekte çok zaman harcıyordu ve çıkan sonuçlar da hızlı cevaplara göre daha düşük kalitedeydi. Ama son dönemde modeller ciddi şekilde geliştiği için bu tür işler oldukça eğlenceli hale geldi; spec'e dökülebilen durumlarda kullanım değeri arttı. Kendi deneyimimde sonnet 3.7, 3.5'e göre büyük bir ilerlemeydi; Gemini 2.5 Pro ise daha da etkileyiciydi. sonnet 4 daha az hata yapıyor ama yine de yazılım mühendisliği açısından (gereksinimleri toplama, teknik çözüm arayışı, mimari tasarım, kullanıcı hikâyeleri ve spec yazımı, kod yazımı) AI'ı doğru yönlendirmek gerekiyor ki kaliteli sonuç alınabilsin. Ayrıca iyi örnekler AI'a ek bağlam olarak verildiğinde etki en üst düzeye çıkıyor. Yakın zamanda OpenAI Realtime API ile uygulama geliştirirken başlangıçta tamamen başarısız oldum, ama çalışma alanına iki sayfa doküman ve bir demo proje ekleyince hemen istediğim sonucu almaya başladım (benim durumda API'yi farklı kullanmam gerekmesine rağmen iyi uydu)
Commit'in 163-172. satırlarında geçen bazı ifadelerde açıkça yanlış olan ya da A/S (authorization server) uygulamasına göre farklı yorumlanabilecek iddialar görüyorum. Auth0'nun authorization server'ında ağ koşullarını hesaba katan bir “leeway” ayarı var, ama bazı authorization server'lar çok daha katı. Her implementasyonun ayrıntılı tasarımı farklı olduğu için, LLM'in yalnızca standartlar (RFC'ler) ve açık kaynak kodlardan yola çıkarak bunu güvenli biçimde uygulama ihtimalinin sonuçta neredeyse sıfırdan elle yazmak kadar insan denetimi gerektirdiğini düşünüyorum
LLM tabanlı araçların gerçekten iş gücünden tasarruf sağlayıp sağlamadığına, yoksa sadece üretkenlik yanılsaması mı yarattığına dair uzun vadeli araştırma sonuçlarını merak ediyorum
Bu tür deneyimler, AI araçlarının gerçekten bir şeyi anlamadığını; yalnızca devasa bir örüntü veri yığınından tesadüfi biçimde emergent çıktılar ürettiğini düşündürüyor
AI ile kod yazmanın geleceği, yazılım mühendislerinin yok olup iş insanlarının düğmeye basarak her şeyi hallettiği LinkedIn/X tarzı bir fanteziden çok, deneyimli mühendislerin AI ile kodun bir kısmını üretip bunu dikkatle inceleyip test ettiği bir yön olacak gibi görünüyor. Asıl önemli soru şu: “kentonv bu kütüphaneyi AI olmadan tek başına daha hızlı yapabilir miydi?”
AI ile birlikte kütüphane yapmak birkaç gün sürdü. Elle kendim yazsaydım birkaç hafta, belki birkaç ay sürebilirdi diye tahmin ediyorum. Yine de bu çok ideal bir örnek. Açık standartlar, net API spec'leri ve zaten iyi bilinen bir platform olduğu için işe yaradı. Workers Runtime'ın kendisini AI ile değiştirmeye çalıştığımızda zaman kazancı çok azdı. Ama benim aşina olmadığım başka insanların codebase'lerinde AI gerçekten çok yardımcı oluyor. Artık yabancı ve karmaşık kod laboratuvarlarına girmek çok daha kolay; eskiden kaçınacağım şeylerde artık gereken değişiklikleri rahatça yapabiliyorum
AI olmadan tek başıma yapsam daha hızlı olur muydu sorusuna kesinlikle hayır derim. Bugünkü araçlar ve giderek gelişen kullanım becerilerimizle, önümüzdeki 3-6 ay içinde AI ile sıfırdan yeni çözümler kodlamanın daha hızlı hale gelmesini bekliyorum. Ama bunun için iyi dokümante edilmiş, yapısı net, hızlı geri bildirim döngüsüne sahip (iyi lint/unit test'leri olan) codebase ekipmanı önemli. O yöne gidiyoruz
Deneyimime göre AI bazı kodları ürettiğinde bunları çok dikkatli inceleyip test etmek gerekiyor ve bu süreç çoğu zaman kodu kendim yazmamdan <i>daha yavaş</i> oluyor. Bu yüzden şu aşamada AI bana çok yardımcı olmuyor. Kötü yardımcı hiç yardımcı olmamaktan beterdir sözündeki gibi, AI şimdilik “kötü yardımcı” gibi
“Deneyimli mühendislerin AI ile kodun bir kısmını üretip dikkatle test ettiği yapı” olacaksa, bu durumda 20 kentonv yerine 2 kişinin yeterli olması gerekmiyor mu diye düşünüyorum. Geriye kalan 18 kişi için iş çıkmaya devam edecek mi? Yazarın örneği teknik olarak zor bir proje ama sıradan LoB (iş uygulaması) geliştirmede ne değişecek merak ediyorum
Deneyimli mühendisler sadece dikkatli review ve test yapacaksa, junior geliştirici pozisyonlarının tamamı AI ile değiştirilirse geleceğin kıdemli geliştiricileri nereden yetişecek? Tekrarlı işlerin bile bu açıdan bir değeri olduğunu düşünüyorum
Bu kadar farklı argüman ve görüşü görmek başlı başına ilginç. Cloudflare'ın internet güvenliği alanındaki lider konumuna yakışır biçimde yeni bir “vibe coding” yaklaşımıyla dünyayı birbirine bağlamaya çalıştığını görmekten memnuniyet duydum. Bu AI promptlarının ve kodlarının başka geliştiricilere de programlamayı keşfetme isteği verdiğini hissediyorum. Vibe programming, depresyonumu aşmamı ve bana uygun şekilde yeniden kod yazabilmemi sağlayan çok anlamlı bir araç oldu. Umarım bu deneyim başkalarına da yardımcı olur. Mevcut ve gelecek nesillerin bu yaklaşımı kullanacağını düşünüyorum. Ancak bunun insanların ruh sağlığı ve psikolojik sorunlarıyla da bağlantılı olabileceğini konuşmamız gerektiğine inanıyorum. Sonuçta bu araçlar insana yardımcı olmak için var; mesele, tutkuyla gelişebilmemiz için onları nasıl kullanacağımız. Açık kaynak dünyasında sadece teknik yetkinliği değil, mantıklı ve düşünceli proje yaklaşımını da gösteren daha çok örnek görmeyi umuyorum. Cloudflare'ı bir kez daha takdir ediyorum
Tipik prompt alışverişi örnekleri derlenmiş. Prompt transcript örneği'nde gerçek maliyetin bile (toplam $6.45) açıklandığı görülüyor. İlgili commit 1, commit 2 gibi kaynaklara da işaret ediliyor. Özellikle deneyimli kişilerden gelen, AI workflow'u hakkında gerçekten işe yarar tecrübe yazılarının hype içinde bu kadar az olmasına şaşırıyorum. Todo listeleri dışında, gerçek canlı kodlama örneklerine dair daha fazla bilgi görmek isterim. antirez ve tptacek'in yazıları da (antirez örneği, tptacek yazısı) faydalı olabilir
Ben “vibecoding”in sonunda ayakta kalamayacağını düşünüyorum. Hâlâ çok iyi programcıların doğrulaması ve bug düzeltmesi gerekiyor; hatta AI'ın düzeltemediği bug'lar da oldu. Sonuç olarak bunlar, zaten o işi iyi bilen insanların hızını artıran yardımcı araçlar. En fazla çok temel bir homepage gibi şeylerde işe yarar; ama onları otomatik üreten araçlar zaten yıllardır var
Vibecoding şu anda düşük riskli işler için ideal. GUI'ler, CRUD uygulamaları, tek seferlik deneyler gibi alanlarda; özellikle güç sahibi olmayanlara yeni bir imkân verdiği için değerli. Bu örneğin vibecoding değil, LLM-assisted coding olduğunu düşünüyorum
Aslında “vibecoding” ifadesinin bir saldırı amaçlı korkuluk gibi kullanıldığını hissediyorum. Çoğu durumda LLM'in yazdığı kodu biraz düzeltip kullanmak da vibe coding sayılmaz mı?
OP'nin yalnızca AI ile üretilmiş kodu değil promptları da paylaşmış olmasına özellikle minnettarım. Ben de kişisel olarak LLM'lerle web dışı kod geliştirirken — özellikle son dönemde SAP ABAP'i tersine mühendislikle çözerek verileri Snowflake'e uyarlayan bir .NET implementasyonu üretmeye çalışırken — sürekli “halüsinasyon” sorunları yaşadım. Başkalarının çok sayıda başarı hikâyesi anlattığını görünce sorun benim promptlarımda sanıyordum, ama burada paylaşılan örnekleri görünce o kadar da uzak olmadığımı fark ettim. Bence LLM'in benim için iyi çalışmamasının nedeni, çözmeye çalıştığım sorunun biraz nadir ve yeni olması. GitHub'da açık biçimde bulunan OAuth gibi çok çalışılmış alanlar olmadığında LLM pek iyi takip edemiyor
Bu tür tekrar eden ve zaten yüzlerce kez uygulanmış kodlar AI için biçilmiş kaftan. Toplam kod yaklaşık 1200 satır, yani küçük bir ölçek. AI kullanıldığı hâlde 2 günden uzun sürmüş olmasına şaşırdım
Son birkaç aydır Cursor üzerinden Claude ile kendi greenfield projemi geliştirirken edindiğim izlenim şu: birincisi, üretkenliğim inanılmaz arttı. İkincisi, zihinsel olarak eskisinden çok daha yorgunum. Üçüncüsü, araçlar kısa sürede gerçekten çok hızlı gelişmeye başladı ve bu iki etki de daha da güçleniyor
Benim ve diğer geliştiricilerin deneyimi de aynı. LLM-assisted coding gerçekten üretkenliği ciddi artırıyor ama enerji tüketimi de o ölçüde yükseliyor. Hatta garip gelecek kadar belirgin
“Bunun daha yorucu olması” üzerine soruyorum. Ben klasik yönteme kıyasla ajanımla (Devstral) daha çok “pair programming” tarzında çalışıyorum ve kodun tamamını tek tek yazmaktansa review etmek çok daha kolay geliyor. Zaman açısından büyük avantaj sağlıyor. Vibe coding'de codebase bağlamı kaybolduğu için daha sonra review etmek ve projeye girmek çok daha zor hale geliyor. Pair programming yaklaşımında ise bağlamı biriktirerek ilerlediğin için review çok daha hızlı oluyor
Ben ise tam tersini yaşıyorum. AI bütün küçük ayrıntıları benim yerime hallettiği için büyük bir rahatlama hissediyorum. Mimari gibi üst düzey hedeflere odaklanma özgürlüğü veriyor
Cloudflare gibi bir şirketten "Too Many Requests" hatası görmek bir bakıma komik geliyor