MCP için Zero-Touch OAuth

 (blog.modelcontextprotocol.io)
1 puan yazan GN⁺ 4 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Enterprise-Managed Authorization (EMA) uzantısı kararlı hale geldi; böylece kurumlar MCP sunucu yetkilerini merkezi olarak yönetebiliyor ve kullanıcılar bir kez giriş yaparak izinli sunuculara erişebiliyor
  • Mevcut yaklaşım, kullanıcı ve sunucu bazında ayrı OAuth onaylarına dayanıyordu; bu da onboarding’i, güvenlik politikalarının uygulanmasını, denetim izlerini ve iş/kişisel hesap ayrımını zorlaştırıyordu
  • EMA, kuruluşun IdP’sini yetki kararlarının sahibi haline getiriyor; yönetici politikayı bir kez tanımladığında kullanıcılar mevcut kurumsal hesaplarıyla gerekli MCP bağlantılarını devralıyor
  • SSO sırasında verilen ID-JAG, MCP sunucusunun yetkilendirme sunucusunda erişim token’ına çevrildiği için kullanıcılar sunucu bazlı onay ekranlarına yönlendirilmiyor
  • Okta, Anthropic, Visual Studio Code ile Asana, Atlassian, Canva, Figma, Granola, Linear ve Supabase ilk destek dalgasında yer aldı; Slack de desteği ekliyor

EMA’nın kararlı hale gelmesi ve kurumsal dağıtım hedefi

  • Enterprise-Managed Authorization (EMA) extension stable durumuna geldi
  • Kurumsal ortamlarda MCP sunucu bağlantılarını yönetirken tekrar eden onaylar ve izin istemleri büyük bir sorun olarak görülüyordu; EMA bu sorunu azaltmak için geliştirilen bir uzantı
  • Kuruluşlar, güvendikleri kimlik sağlayıcısı (IdP) üzerinden MCP sunucularına erişimi merkezi olarak kontrol edebiliyor
  • Son kullanıcılar mevcut kurumsal hesaplarıyla giriş yaptıktan sonra izinli MCP sunucularına bağlanıyor; böylece sunucu bazlı OAuth onayı veya tek seferlik kurulum yükü azalıyor

Kullanıcı bazlı kimlik doğrulama modelinin sınırları

  • Standart MCP yetkilendirme modeli, kullanıcı kapsamlı (user-scoped) ve geleneksel etkileşimli kimlik doğrulama yaklaşımına göre tasarlandı
  • Kişilerin kendi verilerine erişecek hedefleri doğrudan seçtiği tüketici senaryolarına uygun olabilir, ancak kurumsal dağıtımlarda iyi ölçeklenmiyor
  • Kurumsal ortamda özellikle üç sorun büyüyor
    • Her çalışanın sunucuları ayrı ayrı onaylaması gerektiğinden onboarding sırasında hizmet bazında manuel bağlantı kurulması gerekiyor
    • Güvenlik ekipleri, merkezi kontrol veya denetim izi olmadan her kullanıcının verdiği onaya bağımlı kalıyor
    • Kurumsal hesap kullanımını zorunlu kılmak zorlaştığı için kullanıcılar iş araçlarına kişisel hesaplarını bağlayabiliyor
  • Bu sürtünme, MCP benimsenmesini yavaşlatıyor ve zayıf geçici çözümler üretilmesi riskini artırıyor
  • Paylaşılan kimlik doğrulama durumunu koruyacak genel bir standart olmadığında, uygulayıcılar ayrı çözümler üretmek zorunda kalıyor; veri ve araçlar mevcut olsa bile kullanıcı bazlı yetki maliyeti yüzünden çoğu kapalı kalabiliyor

Bir kez onayla, her yerde devral

  • Enterprise-Managed Authorization, kuruluşun IdP’sini MCP sunucu erişimi için yetki kararlarının merkezi haline getiriyor
  • Yöneticiler politikayı bir kez tanımlıyor, kullanıcılar ise mevcut kurumsal kimlikleriyle MCP host’una kimlik doğruluyor
  • IdP; grup üyeliği, roller ve koşullu erişim kurallarına göre erişime izin verebilir veya reddedebilir
  • İç akış şöyle işliyor
    • İstemci, SSO sırasında IdP’den Identity Assertion JWT Authorization Grant (ID-JAG) alıyor
    • İstemci bunu MCP sunucusunun yetkilendirme sunucusuna gönderip bir erişim token’ı ile değiştiriyor
    • Kullanıcı sunucu bazlı onay ekranlarından geçmiyor
  • Bu yapının üç temel etkisi var
    • Yönetici kuruluş için bir sunucuyu etkinleştirdiğinde kullanıcılar mevcut grup ve rol kapsamları içinde otomatik erişim kazanıyor
    • Erişim kararları IdP yönetici konsoluna kaydedildiği için tüm connector’lar için tek ve denetlenebilir bir kayıt sağlanıyor
    • Etkileşimli hesap seçimi adımını ortadan kaldırarak kişisel ve kurumsal hesaplar arasındaki veri akışı karışıklığını azaltmak kolaylaşıyor
  • MCP’nin kurumsal kullanımında hedef, kullanıcı giriş yaptığında istemcinin ek adım olmadan izinli araçlara ve verilere bağlanması

İlk desteklenen ürünler ve ekosistem

  • Bu lansmanda üç grup uygulamaya katılıyor: kimlik sağlayıcıları, istemciler ve sunucular

  • Kimlik sağlayıcıları

    • Okta, desteği sunan ilk kimlik sağlayıcısı
    • Okta kullanan kuruluşlar, Okta’s Cross App Access (XAA) üzerinden desteklenen istemci ve sunuculara MCP erişimi sağlayabiliyor

  • İstemciler

    • Anthropic, Claude’un paylaşımlı MCP katmanına EMA uyguladı
    • Yöneticiler Claude, Claude Code ve Cowork genelinde kullanıcılar için MCP sunucularını onaylayabiliyor
    • Visual Studio Code da IDE içine EMA desteği ekledi

  • Sunucular

    • Asana, Atlassian, Canva, Figma, Granola, Linear ve Supabase EMA’yı destekliyor
    • Slack ve diğer sunucular da desteği ekleme sürecinde
    • Okta’dan Aaron Parecki, Cross App Access protokolünün MCP’nin EMA uzantısına gömülmesinin identity’yi merkezi bir yönetişim katmanına dönüştürdüğünü; güvenlik ekiplerine uyumluluk kontrolleri, kullanıcılara ise akıcı bir deneyim sunduğunu söylüyor
    • Figma’dan Devdatta Akhawe, MCP benimsenmesi arttıkça XAA’nın kurumların MCP dağıtımlarını güvenli biçimde ölçeklendirmesini kolaylaştırdığını belirtiyor
    • Linear’dan Tom Moor ise bir kez giriş yapıldığında tüm MCP connector’larının otomatik yapılandırıldığı deneyime dikkat çekiyor

Belgeler ve katılım kanalları

  • İstemciler, sunucular ve identity platform’ları uzantı spesifikasyonunu inceleyip ürünlerine yeni standart desteği ekleyebilir
  • Enterprise-Managed Authorization page, istemci, sunucu ve yetkilendirme sunucusu için akış gereksinimlerini belgeliyor
  • ext-auth repository ve draft specification üzerinden EMA’daki son değişiklikler ve destek materyalleri takip edilebilir
  • Uzantı tartışmaları, uyumluluk raporları ve yinelemeli geliştirmeler için EMA Interest Group kullanılıyor
  • EMA, MCP topluluğunun bir çalışması; SEP-990 yazarları, ext-auth deposu bakımcıları ve ilk uygulamaları test edip spesifikasyonu ilerleten identity ve MCP sağlayıcıları katkıda bulundu

İlgili okumalar

1 yorum

 
GN⁺ 4 시간 전
Hacker News görüşleri

  • Alışıldık “MCP öldü, gelecek Skills” tartışmasına girmeden önce, MCP’nin skills/CLI’ye kıyasla gerçekten değerli olduğu nokta, kimlik doğrulama akışını ajanının bağlam penceresinin dışına, bazı durumlarda harness’ın da dışına ayırmasıdır
    Bu, güvenlik açısından da doğal olarak önemli ve sıradan kullanıcılar ya da büyük şirketler yapay zeka araçlarını benimserken çok daha kolay bir kullanıcı deneyimi sağlar
    Bağlamın şişmesi veya araç çağrılarının yinelenmesiyle ilgili şikayetleri anlıyorum, ancak kimlik doğrulamayı bu şekilde ele alan yapının açık bir değeri var
    İdeal bir MCP, API’nin önündeki bir kimlik doğrulama geçidi olsa bile yeterince faydalı olabilir

    • Bu uzantı, MCP’nin skills’e kıyasla diğer avantajlarını da iyi gösteriyor: merkezi kontrol, çalışan açısından kullanım kolaylığı, denetim/uyumluluk, dağıtım modeli
      Şu anda skills dağıtımında en iyi yöntemler “bu dosyayı kopyalayıp buraya koyun”, “bu depoyu checkout edip sembolik bağlantı ekleyin”, “slash komutuyla kurun” seviyesinde görünüyor
      Basit olsa da, bu uzantı yöntemiyle yeni bir MCP sunucusunu çalışanlara dağıtmak kadar kolay değil
    • MCP, mükemmel bir denetim izi de mümkün kılar
      Örneğin 6 müşteri şirketinin 6 ayrı Linear hesabını doğrulanmış halde tutup, hangi hesabın kullanılacağını deterministik ve denetlenebilir bir şekilde seçmek gibi bir sorumluluk ayrımı da yapılabilir
    • Gerçek ders, MCP ile skills’in ikili bir karşıtlık olmadığıdır
      Bunlar sadece farklı araçlar ve gereksinimlere göre biri diğerinden daha uygun olabilir ya da olmayabilir
      Bu, bıçakla testere arasında hangisinin daha iyi olduğunu sormaya benzer
    • Bunun dışında MCP, çalışma zamanı ortamı olmadan harici platformları bağlamayı da sağlar
      Bu konu her açıldığında mühendisler sanki Claude Code, yapay zeka ajanları için tek uygulamaymış gibi davranıyor, ama kodlamanın ötesinde pek çok sektörde sayısız kullanım senaryosu var
      Harness, yerel makine yerine buluttaki yalıtılmış ve kısıtlı bir konteynerde çalışıyor olabilir ve rastgele kod çalıştırmaya asla izin verilmeyen bir ortam olabilir
      Buna rağmen müşteri mevcut araçlarını ajana bağlamak istiyorsa, MCP yerleşik kimlik doğrulamaya sahip konektörler sunduğu için tam oturur; skills ise bu alana girmez
    • Arkadaşlarımla restoran yorumları yapılan bir platform geliştiriyorum ve birkaç deneme-yanılmadan sonra MCP’nin doğru yön gibi göründüğünü düşünüyorum
      Sıradan kullanıcılar Claude dizinini bulup skill dosyasını yapıştırmaz
      “Connections” anlaşılması kolay ve MCP’yi yapıştırmak ya da bir marketplace’te bulmak daha kolay
      Ajanın mekanlara ve yorumlara erişmesinin gerçekten faydalı olup olmayacağı ise hâlâ belirsiz

  • Okta, Anthropic, Microsoft, Figma, Linear ve diğerlerinde bu işi yapan herkese büyük tebrikler
    MCP şüphecileri için de işe yarar bir şey var
    Bu, ID-JAG adlı yeni bir token biçimiyle çalışıyor ve https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a... adresinde yer alıyor
    Bu, kesinlikle MCP’ye özel değil; aynı SSO sağlayıcısını kullanan uygulamalar arasında verinin güvenli biçimde paylaşılması gereken her yerde ID-JAG kullanılabilir

    • Bu şirketler yüzünden yazılımın ve yaşam kalitesinin daha kötü hale geldiğini düşününce, ne büyük tebrik gerçekten diye alaycı bir his geliyor

  • Şu anda geliştirdiğim MCP sunucusuna Microsoft Entra ID kimlik doğrulaması eklemeye çalışıyorum ama açıkçası kendimi aptala dönmüş gibi hissediyorum
    WWW-Authenticate başlığıyla istemciye kaynak metadata URL’sini bildirebiliyor ve bunun üzerinden kimlik doğrulama sunucusu olarak Microsoft Entra’yı ve uygulama kayıt kapsamını da belirtebiliyorsunuz
    Ama client_id belirtilemiyor; mantık, her istemcinin yani her ajanın bunu kendi başına oluşturması yönünde
    Oysa Microsoft Entra’nın .../authorize URL’siyle oturum açmayı başlatmak için, Entra’daki uygulama kaydıyla eşleşen bilinen bir client_id gerekiyor; istemcinin rastgele oluşturduğu bir değerin Entra’ya uyması mümkün değil
    Teoride dinamik istemci kaydını desteklemek mümkün ama Microsoft Entra doğal olarak bunu desteklemiyor
    Sonuçta Microsoft Entra’nın önüne kendi dinamik istemci kaydı shim katmanımı koyup herkese aynı statik client_idyi döndürmekten başka yol göremiyorum
    Bu protokolün gerçekten kurumsal ortamlarda herhangi bir workaround olmadan çalışması mı gerekiyor, yoksa çok bariz bir şeyi mi kaçırıyorum bilmiyorum

    • Bariz bir şeyi kaçırıyor gibi görünmüyorsun
      Entra ID dinamik istemci kaydını desteklemiyor ve bu ekosistemin durumu henüz pek iyi değil
      Genelde MCP OAuth, önceden kaydedilmiş geleneksel istemcilerle ele alınıyor ama pratikte birçok MCP istemcisi dinamik istemci kaydının çalıştığını varsayıyor ve client_id belirtme seçeneği sunmuyor
      Yine de bunu destekleyen bazı istemciler var; biraz reklam yapmış olayım, bizim aracımız Erato da destekliyor: https://erato.chat/docs
      Kurum içinde dağıtılan tipik çözümler de genelde MCP erişimini bir web UI üzerinden merkezileştirdiği için bunu destekliyor
      Bir diğer alternatif de MCP gateway; gateway ile servis arasında önceden kayıtlı OAuth kullanıp gateway ile istemci arasında dinamik istemci kaydına izin verebilirsiniz
    • Biz de client_id yüzünden aynı sorunu yaşadık ve güvenlik nedeniyle dinamik istemci kaydını açmak istemedik
      Sonunda uygulamanın OAuth akışına proxy olup sabit kodlanmış bir client_id enjekte etmesini sağladık
      MCP istemcisine dinamik istemci kaydını destekliyormuş gibi davranıyor ama içeride MCP için ayrı bir client_idyi her zamanki gibi kullanıyor
      Örnek burada: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...
    • Daha dün bunu implemente ettim; ana fikir, bu kütüphanenin MCP sunucusunu çalıştırması: https://csharp.sdk.modelcontextprotocol.io/concepts/identity...
      Ardından OpenID ile istemci kaydını yöneten ve JWT üreten bir kimlik doğrulama broker uygulaması yaptım
      Böylece çalışanların departmanına ya da başka ölçütlere göre araçları kullanıp kullanamayacağını ve hangi yetkilere sahip olacağını belirleyebiliyorum
      Sonuç olarak dinamik istemci kaydı gerekiyor
    • Kısa süre önce FusionAuth’ta önceden kayıtlı istemciler kullanma yöntemini dokümante ettik: https://fusionauth.io/docs/extend/examples/controlling-acces...
      DCR’nin daha yeni ve daha iyi kardeşi olan CIMD’yi de değerlendiriyoruz ve aktif şekilde tartışılıyor, ancak henüz sunulmuyor: https://github.com/FusionAuth/fusionauth-issues/issues/3230
      Önerdiğin proxy’ye alternatif olarak, geliştirici portalı gibi bir yerden her MCP istemcisi için PKCE etkin yeni bir Entra client_id oluşturup kullanıcının bu değeri istemciye girmesini sağlayabilirsiniz
      Bunun için CLI komutunu burada buldum; muhtemelen bir API de vardır: https://learn.microsoft.com/en-us/cli/azure/ad/app?view=azur...
      Claude Code ayarları https://code.claude.com/docs/en/mcp, ChatGPT ayarları ise https://developers.openai.com/api/docs/guides/developer-mode adresinde
      Önceden istemci kaydı, geliştiriciler için ideal olmasa da kabul edilebilir ve spesifikasyonda da birinci sınıf yaklaşım olarak ele alınıyor: https://modelcontextprotocol.io/specification/2025-11-25/bas...
      Ana kullanıcı kitlesi şirket içi çalışanlarsa ve MCP sunucusuna erişmek için kurulum talimatlarını takip edebiliyorlarsa bu yaklaşım işe yarar
      Ama hedef kitle geliştiriciler değil de geniş çaplı bir herkese açık entegrasyon ise, bu kesinlikle kabul edilebilir değil; MCP’nin büyük gücü ve fırsatı da tam burada yatıyor

  • Bunu Anthropic'te Okta ve çeşitli MCP iş ortaklarıyla birlikte yapan kişilerden biriyim
    Bu modelin Claude içinde şekilleniyor olması çok heyecan verici ve MCP spesifikasyonunda EMA kararlı bir genişletme haline geldiğine göre bunu diğer kimlik sağlayıcıları ve istemcilere de yaymak istiyoruz
    Geri bildiriminiz varsa buraya bırakmanız harika olur; gerçek kullanım deneyimlerini ve nasıl iyileştirebileceğimizi her zaman duymak isteriz

    • Uzun zaman olmuş
      Bir süredir MCP'ye bakmıyordum ama bu, kuruluşlarda MCP'yi daha güvenli hale getirmek ve dinamik istemci kaydının zayıflıklarını gidermek için oldukça uygun görünüyor
      Artık istemciler ve onaylı yönlendirme URI'ları kimlik sağlayıcı ve kuruluş tarafından doğrudan ayarlanabildiği için, karışık vekil saldırıları veya phishing gibi DCR tabanlı saldırılar daha geniş ölçekte azaltılabiliyor
      Ayrıca kimlik sağlayıcının veya kuruluşun DCR desteklemediği durumlarda MCP sunucusunun uygulamak zorunda kaldığı yetkilendirme mantığı da azalıyor; bu da büyük bir avantaj
      Dezavantajı, tüketici kullanımında hâlâ DCR gerekiyor gibi görünmesi
      GitHub, GitLab, Google gibi tüketici OAuth sağlayıcıları statik MCP istemci/sunucu kaydını desteklerse, istemci statik bir client_id gömerse ve kullanıcılar ilgili kimlik sağlayıcıyla oturum açıp bağlantıyı doğrudan yönetirse bu çözülebilir olabilir
      Genel olarak XAA/EMA güvenlik ve kullanılabilirlik açısından DCR'den çok daha üstün görünüyor
      Endişe verici noktalar da DCR'ye göre çok daha kolay çözülebilir ve güvenlik etkisi daha düşük. Çünkü saldırgan kendi istemcisini kaydedemez ve MCP sunucusu geliştiricilerinin düşebileceği tuzaklar da azalır
    • Genel bir “uygulama” için harika, ama bizim için kullanıcıların MCP'yi kurmadan da daha düşük sürtünmeyle ajan tarzı etkileşime girebilmesi çok önemli
      Bir tür geçici oturum ya da bant dışı token deposu olsa iyi olurdu
      Kullanım senaryosu şu: satış sürecinde alıcılar ve satıcılar çok fazla bilgi alışverişi yapıp analiz etmek zorunda kalıyor ve bu analiz giderek daha ajan tabanlı hale geliyor
      MCP'deki sorun, ilk kurulum sürtünmesinin kullanıcının doğrudan giriş yapıp gereken bilgileri getirmesinden çok daha yüksek olması
      MCP düzenli ve sık etkileşimler için iyi, ama hızlı tek seferlik oturumlarda çok sorun çıkarıyor
      Claude'da “X, Y, Z'den belgeleri getir” dendiğinde Claude ilgili web sitelerine erişse ve siteler temel kullanım bilgileriyle birlikte kullanıcının tarayıcıda açabileceği bir giriş bağlantısı döndürse harika olurdu
      Kullanıcı tarayıcıda kimlik doğrulaması yapar, geri çağrı benzersiz ve kısa ömürlü tek kullanımlık bir token döndürür, ardından bu token sonraki site isteklerinde değiştirilirse iyi olurdu
      Böylece kullanıcıyı hızlıca doğrularken iş sırasında oturum durumunu da koruyabilirsiniz
    • Microsoft Entra, yani Azure AD ekibiyle iletişim olup olmadığını merak ediyorum
      Yakında bir şeyler beklemeli miyiz, yoksa bunun için epey zaman mı gerekecek bilmek isterim
    • Çıkış için tebrikler
      Ana kullanım alanı şirket çalışanları gibi görünüyor; ama müşteri ya da premium freemium kullanıcılar gibi merkezi olmayan kullanıcılar için de benzer bir değer olup olmadığını merak ediyorum
      Kafamda pek canlandıramadım, bu yüzden neyi kaçırdığımı merak ettim; ilgili cevabı da sanırım burada gördüm: https://news.ycombinator.com/item?id=48594381
    • Bunun henüz gerçekten kullanılabilir olmadığını, hâlâ SEP aşamasında olduğunu doğrulamak istiyorum

  • Bu gerçekten harika
    Son birkaç ayda MCP tarafındaki insanlarla bazı SEP'ler ve Go için deneysel SDK'lar üzerinde çalışabilmiş olmak büyük şanstı
    Eskiden “bu sadece bir API”, “yine bir soyutlama daha çıkarmışlar” diyen şüphecilerden biriydim
    İnsanların kaçırdığı şey, MCP'deki “P” harfinin yanlış bir algı yaratması
    Geleneksel bir uygulama geliştirirken formlar, arayüz, istek/yanıt işleme, çift yönlü kanallar, uzun süren işler, kimlik doğrulama vb. kurmanız gerekir
    MCP ile bu ortak katmanın %80'i halledildiği için MCP bir protokol olmasının yanında pratikte daha çok bir uygulama çatısına benziyor
    Entegre kimlik doğrulama muazzam bir güçlendirme ve ileride daha da iyi şeyler bekleniyor

  • Yaptığım işin dışarıdan görünür olması biraz tuhaf ama güzel
    Atlassian'da bu akışın RAS tarafı uygulamasını yaptım
    CIMD, daha iyi tenant desteği gibi konularda bu akışta kesinlikle yinelenen iyileştirmeler olacak
    Anthropic, Okta ve Atlassian'da bunu hayata geçiren herkes harikaydı

  • Web desteği verip doğrudan uzun ömürlü cookie vermeye izin verseniz iyi olurdu
    OAuth sunucusu olmadan bunu yapmak için spesifikasyonu hackleyip OAuth handshake üzerinden cookie geçirmeye çalıştım
    Buna izin verilmemesi gerçekten sinir bozucu
    Cookie yoksa web sayfasını açarsınız, cookie ayarlandığında kapatıp saklarsınız, hepsi bu
    Hatta MCP hakkında 80 sayfalık küçük bir kitap bile yazdım ama yine de bitmeyen bir hayal kırıklığı yaşıyorum

    • MCP projesinin baş bakımcılarından biriyim; bu yaklaşım birçok senaryoda ölçeklenmiyor
      Hem kullanılabilirlik hem de güvenlik açısından sorunları var ve cookie'ler tarayıcılar için tasarlanmıştır
      MCP sunucuları ve istemcileri çoğu zaman tarayıcının garanti olmadığı ortamlarda çalışır
    • Bu neredeyse “lütfen kimlik bilgilerimin çalınmasına izin verin” demek gibi
      Uzun ömürlü kimlik bilgileri büyük bir sorumluluk yükü getirir

  • Bunu birkaç kez okudum ve kesinlikle faydalı
    Denetim ve erişim kontrolünü tek bir kimlik sağlayıcıda merkezileştiriyor; ayrıca gerektiğinde token değişimini üstlenen bir proxy API gateway gibi de davranabilir
    Bu, alandaki diğer oyuncuların da benimsediği bir yaklaşım
    Kişisel olarak, kimlik sağlayıcının ben farkında olmadan yetkilerimi istemciye devretmesi beni biraz rahatsız ediyor
    Belki de tarayıcıda kullanıcının bulunduğu akışlara fazla alışkın olduğum içindir; giderek makineler için erişimin merkezileşmesine evriliyormuş gibi geliyor
    Kurumsal ortamda kimlik bireyden çok şirkete ait olduğu için bu kabul edilebilir olabilir
    Ama bunu müşteri kimliği tarafına entegre etmek bambaşka bir zorluk ve kimlik sağlayıcı, istemci ve kaynak yetkilendirme sunucusu arasında böyle bir güven oluşturmak muhtemelen kolay olmayacaktır

    • Bu entegrasyonun tüketici alanında çalışmasını engelleyen teorik bir bariyer yok
      Örneğin GitHub'da oturum açtıysanız Sentry'de de otomatik giriş yapmanızı sağlayacak bir güven ilişkisi kurulabilir
      Önümüzde hâlâ yapılacak çok iş var ama şu an için en net kullanım alanı, dediğiniz gibi, kurumsal taraf
      Yöneticiler, tek tek çalışanların oraya buraya tıklayıp rastgele kimlik bilgileri seçmesini istemez

  • C1'de hem dahili MCP kullanımı hem de ürün içindeki MCP Gateway tarafında MCP kimlik doğrulaması büyük bir baş belasıydı; bu yüzden bunun gelmesi çok sevindirici.
    Bugün C1, EMA kimlik sağlayıcısı olarak çalışmayı destekleyen bir sürüm yayımladı ve kısa ömürlü, kapsamı sınırlı token'lar veriyor.
    Artık Linear ve kullandığımız diğer MCP'lere bağlanıp tekrarlayan OAuth akışlarından kurtulmak istiyorum.
    Claude, yerleşik bağlayıcılarının bir kısmında, en azından Slack'te, bunu sihir gibi yapıyordu ve deneyim oldukça iyiydi.
    Açıklamak gerekirse C1'de VPE'yim; daha derine inmek isteyenler için yaklaşımı burada belgelendirdim: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

  • Bunun normal OAuth'a göre ne avantaj sağladığını pek anlayamıyorum.
    Sanırım yetkilendirme akışı karşılaştırma örneği gerekiyor.

    • Normal OAuth'ta son kullanıcı, verilerini her bir uygulamayla paylaşmaya ayrı ayrı onay verir.
      Bu, tüketici kullanım senaryolarında, yani son kullanıcının kendi verisine sahip olduğu durumlarda anlamlıdır.
      Ama birçok iş kullanım senaryosunda veriyi paylaşması ve erişimi kontrol etmesi gereken taraf son kullanıcı değil, şirkettir.
      Acme çalışanı olarak benim, Acme'nin Google Drive verilerini Claude'a ya da ChatGPT'ye bağlayıp bağlamamaya karar vermemem gerekir; buna IT departmanı karar vermelidir.
      Enterprise-Managed OAuth veya Cross App Access (XAA), IT yöneticisinin merkezi olarak kontrol ettiği paylaşım modelini OAuth çerçevesinin içine getirerek mevcut ekosistemle birlikte çalışmasını sağlar.
      Ayrıca veri paylaşımı onay yönetimini çalışanlardan IT yöneticisine taşımak, kullanıcı deneyimi açısından da büyük fayda sağlar.
      Çalışanların hesap bağlamak için birden fazla OAuth akışından geçmesi gerekmez; IT yöneticisi paylaşım kontrollerini zaten önceden ayarlamış olur.
      İşe başladığınız ilk gün Slack'in zaten Zoom, Drive, Calendar vb. ile bağlı olduğunu düşünün.
    • Avantajı, kullanıcının hangi uygulamaların kendi bilgilerini birbirleriyle paylaşmak üzere yetkilendirildiğini kontrol etmesine veya buna onay vermesine gerek olmamasıdır.
      Çünkü erişim devri kararı kimlik sağlayıcı politikası düzeyinde verilir.
      Kullanıcı, hangi uygulama veya hizmetlerin kendi bilgilerini paylaşmasına izin verildiğini hayatı boyunca hiç öğrenmeyebilir.
      Bir dakika, bu gerçekten bir avantaj mı? ;-)