Val Town'a göre OAuth'un DCR ve CIMD özellikleri her uygulamanın diğer her uygulamaya bağlanmasını sağlayabilir

Tek tıkla bağlantı için bir protokol

Kodlama platformu Val Town, Model Context Protocol (MCP) ekosisteminin yaygınlaştırdığı iki OAuth uzantısının, herhangi bir uygulamanın manuel kurulum gerektirmeden başka herhangi bir uygulamaya kimlik doğrulaması yapmasını sağlayabileceğini öne sürüyor — böylece Zapier gibi connector marketlerinin var olma nedeni olan entegrasyon sorunu çözülüyor. Val Town blogunda yayınlanan ve Hacker News'in ana sayfasında öne çıkan yazı, tanıdık bir yakınmayla başlıyor: Zapier'in connector kütüphanesine duyulan imrenme ve tek tıkla bağlantı isteği.

Her connector'ın ardındaki n² sorunu

Yazar, uygulamadan uygulamaya entegrasyonu klasik bir n² sorunu olarak çerçeveliyor: her uygulamanın diğer tüm uygulamalarla konuşabilmesi için her sağlayıcıda OAuth client olarak kayıt olması gerekiyor. Yazıya göre kayıt işlemi iyi ihtimalle bir developer portalda birkaç dakikalık tıklama anlamına geliyor, ama formlar, demo videoları, imzalı evraklar ya da bir insanla görüşme de gerektirebiliyor — ve her uygulama, kullanıcılarının istediği her servis için bu süreci tekrarlamak zorunda. OAuth, yazarın istediği evrensel protokole yakın, ama client kaydı adımı kombinasyonel maliyeti ayakta tutuyor.

Dynamic Client Registration

Yazı, bunu öngören Anthropic ve OpenAI'ye atıf yapıyor: asistanları, tüm müşteri uygulamaları için OAuth client tutmadan onlara erişmek zorundaydı, bu yüzden MCP spesifikasyonu az bilinen bir OAuth uzantısı olan Dynamic Client Registration'ı (DCR) içine aldı. DCR ile bir uygulama, OAuth client'ı anında oluşturuyor ve daha önce hiç karşılaşmadığı bir servise karşı hemen bir authorization akışı başlatıyor.

Val Town, DCR ile kendi MCP sunucusunu geliştirirken karşılaştı; bu sunucu, kullanıcıların Claude ve ChatGPT'den Val Town'a giriş yapmasını sağlıyor. Şirket bu ilkel üzerine, bir uygulamaya iki satır kodla "Login with Val Town" özelliği ekleyen std/oauth adlı bir middleware kütüphanesi kurdu; OAuth client, ilk kullanıcı giriş yaptığında perde arkasında oluşturuluyor. Yazar bunun sihir olmadığını dikkatle belirtiyor — Val Town hem authorization sunucusunu hem de uygulamanın altyapısını işletiyor — ama kütüphanenin diğer altyapılara ve DCR destekleyen her sağlayıcıya uyarlanabileceğini savunuyor.

Client ID Metadata Documents

DCR'ın kendisinin uygulanması zor olabileceği için yazı ayrıca Client ID Metadata Documents'ı (CIMD) öne çıkarıyor. CIMD ile hiç ön kayıt yok: bir uygulama, OAuth client verisini bir URL'de kendi barındırıyor ve hemen bir OAuth akışı başlatabiliyor. Örnek olarak Notion gösteriliyor; kayıt endpoint'i de dahil olmak üzere sunucu metadata'sını well-known bir konumda yayınlıyor, böylece CIMD destekleyen her uygulama, daha önce hiç duymamış olsa bile Notion ile istediği anda bir authorization akışı başlatabiliyor.

Yazar, artık binlerce uygulamanın DCR'ı, yüzlercesinin ise CIMD'yi desteklediğini bildiriyor ve bu alışılmadık hızlı yayılımı, sektörün tamamının ChatGPT ve Claude ile uyumlu MCP sunucuları inşa etme yarışına bağlıyor — bu yarış, o uygulamaları istemeden birbirine bağlanabilir hale getirdi. Bir gösterim olarak yazar, 3.613 connector ortaya koyan ve uygulama Val Town'da kopyalandığında hepsi tek bir OAuth client kaydedilmeden anında çalışan bir demo uygulama geliştirdi.

Hâlâ çalışmayan şeyler

Yazı, hedefin henüz karşılanmadığını açıkça söylüyor ve üç eksik listeliyor.

Birincisi, birçok DCR endpoint'i gerçek anlamda dinamik değil. Demodan Google Ads'e bağlanma girişimi, redirect host'un sağlayıcının platform kataloğunda bulunmadığını söyleyen bir hatayla sonuçlanıyor; yani pratikte ön kayıt hâlâ gerekiyor.

İkincisi, DCR ve CIMD tokenları yalnızca bir sağlayıcının MCP sunucusu için geçerli olabilir, REST API'si için değil — bu da, kullanıcıları örneğin bir Stripe paneli inşa etmek isteyebilecek bir kodlama platformu için ciddi bir kısıt. Yazı iki yüzey arasında keskin bir ayrım yapıyor: REST API'leri, sözleşmeler değiştiğinde kod kırıldığı için kararlılık vaat ederken, MCP sunucuları kullanıcı arayüzleri gibi değişime tahammül ediyor, çünkü her çağrının iki tarafında da bir LLM var ve bir şey farklı davrandığında uyum sağlayabiliyor. Val Town'un kendi çözümü, DCR ile elde edilen tokenları hem MCP sunucusunda hem de REST API'sinde kabul etmek.

Üçüncüsü, araç eksik. Yazar, demodaki listeyi üçüncü taraf bir kaynaktan kazıyarak oluşturduğunu belirtip herkese açık bir connector kayıt defteri çağrısı yapıyor.

Neden önemli

Uygulamalar arası entegrasyon tarihsel olarak developer portallar, evrak işleri ve sağlayıcı başına pazarlıkla engellenmişti; middleware şirketleri de connector kütüphaneleri üzerine iş kurgulayabildiği için bu böyleydi. DCR ve CIMD, benimsemelerini sağlayan yapay zeka asistanlarının ötesinde standart uygulama haline gelirse bu maliyet çöküyor: küçük bir uygulama, daha önce yalnızca büyük platformların karşılayabildiği bağ dokusuna kavuşabilir. MCP patlaması, yalnızca yapay zeka araç erişimi için değil, ama istemeden uygulama uygulamaya kimlik doğrulamasını standartlaştırması bakımından da önemli hale gelebilir. Bunun gerçekleşip gerçekleşmeyeceği, Val Town yazısının henüz evrensel olmadığını gösterdiği iki tavize bağlı: sağlayıcıların gerçek anlamda dinamik kaydı onurlandırması ve tokenların hem MCP hem de REST yüzeylerinde çalışmasına izin vermesi.