MCP Yetkilendirme Özelliğinin Derinlemesine İncelemesi (2025-03-26 baskısı)

MCP (Model Context Protocol), AI modellerinin harici araçlar ve hizmetlerle etkileşimde bulunmasına olanak tanıyan açık bir standarttır. Endüstri tarafından geniş ölçüde kabul edilmiştir. MCP, HTTP tabanlı taşıma yöntemlerini desteklediğinden, Uzaktan MCP Sunucusu, MCP ekosisteminde giderek daha önemli bir rol oynayacaktır.

Yerel MCP Sunucusu'ndan farklı olarak, her kullanıcının kendi sunucu örneğini çalıştırmasına izin veren, Uzaktan MCP Sunucusu, tüm kullanıcıların aynı MCP Sunucu hizmetini paylaşmasını gerektirir. Bu durum, MCP Yetkilendirme Özelliği tarafından çözülmesi amaçlanan ana problemi gündeme getirir: MCP Sunucusunun kullanıcı adına kullanıcı kaynaklarına nasıl erişim sağlayabileceği.

Bu makale, MCP Yetkilendirme Özelliği hakkında derinlemesine bir analiz yapacaktır. MCP Yetkilendirme Özelliğinin tasarım ilkelerini anlamanıza ve MCP Yetkilendirme'nin nasıl uygulanabileceği konusunda bazı yönler sunacaktır. Bu Özellik hâlâ gelişmekte olduğundan, Kişisel deneyimlerime dayanarak Yetkilendirme uygulayıcı olarak bazı düşüncelerimi paylaşacağım, bunlar şunlardır:

• Bir yetkilendirme çerçevesi olarak OAuth 2.1'in avantajları ve sınırlamaları
• Hem Yetkilendirme Sunucusu hem de Kaynak Sunucusu olarak MCP Sunucusunun çift rolünün zorlukları
• Tam bir Yetkilendirme Sunucusu uygulamanın pratik karmaşıklığı
• Üçüncü taraf yetkilendirme devredilmesi için uygun senaryoların analizi
• Dinamik İstemci Kaydı'nın pratik karşılaştırmaları
• MCP Sunucusu'nun kaynak sınırlarını net bir şekilde tanımlamanın önemi

MCP Yetkilendirme Özelliği Genel Bakış#

MCP Yetkilendirme Özelliği, MCP Sunucusu (Uzaktan) ve MCP İstemcisi arasında kimlik doğrulama sürecini tanımlar.

Bu Özelliği OAuth 2.1 üzerine inşa etmenin çok makul bir tercih olduğunu düşünüyorum. OAuth, bir yetkilendirme protokolü çerçevesi olarak, kullanıcıların üçüncü taraf uygulamalarına, kullanıcı kaynaklarına kendi adlarına erişim izni verme sorununu çözer. OAuth'a aşina değilseniz, daha fazla bilgi için AuthWiki-OAuth sayfasını inceleyebilirsiniz.

MCP İstemcisi ve MCP Sunucusu senaryosunda, bu "kullanıcıların MCP İstemcisine MCP Sunucusundaki kullanıcı kaynaklarına erişim izni verme" ile ilgilidir. "MCP Sunucusundaki kullanıcı kaynakları" şu anda esas olarak MCP Sunucusunun sağladığı araçlara veya MCP Sunucusu'nun arka plan hizmetleri tarafından sağlanan kaynaklara atıfta bulunmaktadır.

OAuth 2.1 kimlik doğrulama sürecini uygulamak için, protokol bir MCP Sunucusunun, OAuth 2.1 kimlik doğrulama sürecini tamamlamak için MCP İstemcisi ile çalışmak için aşağıdaki arayüzleri sağlamasını gerektirir:

• /.well-known/oauth-authorization-server: OAuth sunucu meta verileri
• /authorize: Yetkilendirme isteği için kullanılan yetkilendirme son noktası
• /token: Jeton değişimi ve yenileme için kullanılan jeton son noktası
• /register: Dinamik istemci kaydı için kullanılan istemci kayıt son noktası

Kimlik doğrulama süreci şöyledir:

Özellik, MCP Sunucusunun üçüncü taraf yetkilendirme sunucuları aracılığıyla yetkilendirme devretmesini nasıl desteklediğini de belirtir.

Özellikteki örnek akış aşağıdaki gibidir (Özellik içeriğinden):

Bu senaryoda, MCP Sunucusu üçüncü taraf bir yetkilendirme sunucusuna yetkilendirmeyi devrederken, yine de MCP İstemcisi için bir yetkilendirme sunucusu olarak hareket etmektedir. Bunun nedeni, MCP Sunucusunun kendi erişim jetonunu MCP İstemcisine vermesi gerektiğindendir.

Bana göre, bu senaryo, MCP Sunucusunun üçüncü taraf kaynaklara (örneğin, Github repo'ları gibi) erişmek için MCP İstemcisini kullanıcı adına yetkilendirmek yerine daha uygundur.

Özetle, protokole göre, MCP Sunucusu OAuth'da hem Yetkilendirme Sunucusu hem de Kaynak Sunucusu rolleri oynamaktadır.

Sıradaki, MCP Sunucusunun Yetkilendirme Sunucusu ve Kaynak Sunucusu olarak sorumluluklarını tartışalım.

MCP Sunucusu olarak yetkilendirme hizmeti#

MCP Sunucusu Yetkilendirme Sunucusu olarak hareket ettiğinde, bu, MCP İstemcisi'nin son kullanıcısının MCP Sunucusu üzerinde kendi kimliğine sahip olduğu anlamına gelir. MCP Sunucusu, bu son kullanıcının kimliğini doğrulamaktan ve MCP Sunucusu kaynaklarına erişim için bu son kullanıcıya bir erişim jetonu vermekten sorumludur.

Yukarıda bahsedilen MCP Yetkilendirme Özelliği tarafından gerektirilen Yetkilendirme ile ilgili arayüzler, MCP Sunucusunun Yetkilendirme Sunucusunun bir uygulamasını sağlaması gerektiği anlamına gelir.

Ancak, Yetkilendirme Sunucusu işlevselliğini MCP Sunucusunda uygulamak, geliştiriciler için önemli bir zorluktur. Bir yandan, çoğu geliştirici OAuth ile ilgili kavramlara aşina olmayabilir. Diğer yandan, Yetkilendirme Sunucusu'nu uygularken dikkate alınması gereken birçok detay vardır. Eğer bir geliştirici ilgili bir alandan gelmiyorsa, uygulama sırasında güvenlik sorunları gibi sorunlar ortaya çıkarabilir.

Yine de, protokolün kendisi MCP Sunucusunun yalnızca Yetkilendirme Sunucusu işlevselliğini kendisinin uygulamasını kısıtlamaz. Geliştiriciler, bu Yetkilendirme ile ilgili son noktaları diğer yetkilendirme sunucularına tamamen yönlendirebilir veya proxy olarak kullanabilirler. Bu durum, MCP İstemcisine, MCP Sunucusunun Yetkilendirme Sunucusu işlevselliğini kendisinin uyguladığından farklı değildir.

Merak edebilirsiniz, bu yaklaşım yukarıda belirtilen devredilmiş üçüncü taraf yetkilendirme yöntemini mi kullanmalı?

Benim bakış açıma göre, bu, büyük ölçüde, bağlantılı üçüncü taraf yetkilendirme hizmetinin kullanıcılarının, MCP Sunucusunun son kullanıcıları ile aynı olup olmadığına bağlıdır. Bu, üçüncü taraf yetkilendirme hizmeti tarafından size verilen erişim jetonunun doğrudan MCP Sunucunuz tarafından tüketileceği anlamına gelir.

• Eğer öyleyse, MCP Sunucunuzdaki Yetkilendirme ile ilgili arayüzleri tamamen üçüncü taraf yetkilendirme hizmetlerine yönlendirebilirsiniz.

• Eğer değilse, protokolde belirtilen devredilmiş üçüncü taraf yetkilendirme yaklaşımını kullanmalısınız. MCP Sunucunuzda, MCP Sunucusunun kendisi tarafından verilen erişim jetonları ile üçüncü taraf yetkilendirme hizmetleri tarafından verilen erişim jetonları arasında bir eşleme ilişkisi sağlamanız gerekiyor.

Tecrübelerime göre, protokolde belirtilen devredilmiş üçüncü taraf yetkilendirme yaklaşımı, pratik uygulama senaryolarında muhtemelen biraz belirsizdir. Protokol, üçüncü tarafların MCP Sunucusunun yetkilendirme sürecini tamamlamasına yardımcı olmasını öneriyor gibi görünüyor, ancak yine de MCP Sunucusunun kendi Erişim jetonunu çıkarmasını gerektiriyor. Bu aslında MCP Sunucusunun, Yetkilendirme Sunucusu olarak Erişim jetonları verme sorumluluğunu taşımaya devam etmesi anlamına gelir, bu da geliştiriciler için daha fazla kolaylık sağlamaz. Protokolün yazarları, doğrudan üçüncü taraf erişim jetonlarını MCP İstemcisine döndürmenin bazı güvenlik sorunları (sızma/suistimal gibi) getireceğini düşündükleri için bu yaklaşımı seçmiş olabilirler.

Tecrübelerime göre, protokolde belirtilen devredilmiş üçüncü taraf yetkilendirme için en uygun senaryo, "kullanıcıların MCP Sunucusuna üçüncü taraf kaynaklara erişim izni vermesi" senaryosu olmalıdır. Örneğin, bir MCP Sunucusu, bir kullanıcının Github Repo'suna erişmesi ve Repo'nun kodunu bir kod dağıtım platformuna dağıtması gerektiğinde, kullanıcı MCP Sunucusuna Github Repo'suna erişim izni ve kod dağıtım platformuna erişim izni vermelidir.

Bu senaryoda, MCP Sunucusu MCP İstemcisi için bir Yetkilendirme Sunucusudur, çünkü son kullanıcıların MCP Sunucusunda kendi kimliği vardır. MCP Sunucusu, üçüncü taraf kaynaklar (bu durumda Github) için üçüncü taraf İstemci'dir. Kullanıcı kaynaklarına Github'da erişmek için kullanıcı iznini alması gerekir. MCP İstemcisi ve MCP Sunucusu arasında ve MCP Sunucusu ile üçüncü taraf kaynaklar arasında, kullanıcı kimlikleri ayrılır. Bu, MCP Sunucunun kendisi tarafından verilen erişim jetonları ile üçüncü taraf yetkilendirme hizmetleri tarafından verilen erişim jetonları arasında bir eşleme ilişkisi sağlamanın anlamlı kılar.

Bu sebeple, protokoldeki devredilmiş üçüncü taraf yetkilendirme protokolü, "kullanıcıların üçüncü taraf Kaynak Sunucular üzerindeki kullanıcı kaynaklarına erişim için MCP Sunucusunu yetkilendirmesi" sorununu çözmelidir.

Kaynak Sunucusu olarak MCP Sunucusu#

MCP Sunucusu Kaynak Sunucusu olarak davrandığında, MCP Sunucusunun, MCP İstemcisi'nin isteğinin geçerli bir erişim jetonu taşıyıp taşımadığını doğrulaması gerekir. MCP Sunucusu, erişim jetonunun kapsamına göre MCP İstemcisi'nin belirli kaynaklara erişimine izin verilip verilmemesine karar verecektir.

MCP tanımına göre, MCP Sunucusu tarafından sağlanan Kaynak, MCP İstemcisinin kullanacağı araçlar olmalıdır. Bu senaryoda, MCP Sunucusu yalnızca kullanıcılara belirli araçlara erişim izni verip vermediğine karar vermelidir.

Ancak gerçek dünya senaryolarında, MCP Sunucusu tarafından sağlanan bu araçlar, aynı zamanda MCP Sunucusu hizmet sağlayıcısının kendi Kaynak Sunucusu ile etkileşimde bulunmalıdır. Bu durumda, MCP Sunucusu tarafından istemci isteğinden elde edilen erişim jetonu, kendi Kaynak Sunucusuna erişmek için kullanılır. Çoğu durumda, MCP Sunucusu ve araçların arkasındaki Kaynak Sunucu aynı geliştiricidir. MCP Sunucu, Müşteri İstemcisine kullanmaları için kendi arka plan kaynaklarının bir arayüzünü sağlar. Bu durumda, MCP Sunucusu ve arka plan kaynaklarının aynı Yetkilendirme Sunucusu tarafından verilen aynı erişim jetonunu paylaşabilir.

Bu durumda, MCP Sunucusunun Kaynak Sunucusu olduğunu söylemektense, kendi hizmetinin Kaynağını ve araçlarını sağlamaktansa, mevcut Kaynak Sunucunun MCP Sunucusu olarak MCP İstemcisinin kullanması için araçlar sağlayarak daha anlamlıdır.

Kendi Kaynak Sunucusunun sağladığı kaynakları, MCP Sunucusu tarafından sağlanan Kaynaklara dahil etmek, gerçek dünya senaryolarını dikkate almaktan daha fazlasıdır. Ancak, kişisel olarak, MCP Sunucusu tarafından sağlanan Kaynakların yalnızca MCP istemcisi tarafından kullanılan araçlar olmasını tercih ederim, ve araçların bağımlı olduğu kaynakların MCP Sunucu tarafından başka Kaynak Sunucularından (ilk taraf ve üçüncü taraf dahil) elde edilen kaynaklar olmasını tercih ederim. Bu şekilde tüm gerçek dünya senaryoları kapsanabilir.

MCP yetkilendirmesi nasıl çalışır?#

MCP Sunucusunun Yetkilendirme Sunucusu ve Kaynak Sunucu olarak sorumluluklarını anladıktan sonra, MCP Yetkilendirme'nin nasıl spesifik olarak çalıştığını biliriz:

Dinamik İstemci Kaydı#

Özellik, Yetkilendirme Sunucusunun İstemcileri nasıl tanımladığını da tanımlar. OAuth 2.1, MCP İstemcisinin kullanıcı müdahalesi olmadan otomatik olarak OAuth istemci kimliği elde etmesini sağlayan Dinamik İstemci Kaydı Protokolü sunar.

Özelliğe göre, MCP Sunucusu OAuth 2.0'ın Dinamik İstemci Kaydı Protokolünü desteklemelidir. Bu şekilde, MCP İstemcisi yeni sunuculara otomatik olarak kaydolup OAuth istemci kimliği elde edebilir. MCP senaryolarında bu yaklaşımın önerilmesinin ana nedeni şunlardır:

• MCP İstemcisi, önceden tüm olası sunucuları bilemez
• Manuel kayıt kullanıcılar için sorun yaratır
• Yeni sunucularla bağlantıyı sorunsuz hale getirir
• Sunucular kendi kayıt politikalarını uygulayabilir

Ancak, pratik perspektiften, MCP senaryolarında Dinamik İstemci Kaydı'nın uygulanması hakkında bazı düşüncelerim var:

• Pratik OAuth hizmet uygulamalarında, İstemci genellikle belirli bir iş uygulamasına spesifik bir şekilde birbiriyle ilişkili olur. İstemciyi dinamik olarak oluşturmak, OAuth hizmetlerinde ilgili kaynakları (kullanıcılar, uygulama vb.) etkili bir şekilde yönetmeyi zorlaştırabilir. OAuth hizmet sağlayıcıları genellikle bağlanmış İstemciler üzerinde net bir kontrol sahibi olmayı tercih ederler, herhangi bir istemcinin istediği gibi bir İstemci olarak kaydolmasına izin vermezler.
• Birçok OAuth hizmeti, kullanıcıların İstemcileri dinamik olarak oluşturmalarını önermez veya izin vermez, çünkü bu hizmetin kötüye kullanılmasına yol açabilir. Çoğu olgun OAuth hizmet sağlayıcısı (GitHub, Google vb. gibi) geliştiricilerin, geliştirici konsolları aracılığıyla İstemcileri manuel olarak kaydırmalarını ister ve ayrıca uygulama, çağrı URL'si gibi ayrıntılı bilgiler sağlamalarını da gerekebilir.
• OAuth İstemcisini manuel olarak kaydetmek aslında geliştirme sırasında bir kez yapılan bir işlemdir ve her son kullanıcının yapması gereken bir şey değildir. Geliştiricilere büyük bir yük getirmeyecektir.
• Genel İstemci (yerel uygulamalar, tek sayfa uygulamaları vb. gibi) için, dinamik kayıt olmadan OAuth akışını uygulamak için daha güvenli yollarımız vardır. İstemci kimliği, PKCE (Kod Tarafından Değiştirme Anahtarı) ile birleştiğinde, Genel İstemci için yeterince güvenli bir OAuth akışı sağlar.
• Protokol, Dinamik İstemci Kaydı kullanmanın, istemcilerin daha önce istemci kimliğini bilmesini önleyebileceği belirtilse de, aslında, MCP İstemcisi, Uzaktan MCP Sunucusunun adresini önceden bilmek zorundadır. Eğer böyleyse, Uzaktan MCP Sunucusunun adresini geçirirken istemci kimliğini belirtmek ek bir sorun yaratmaz. Veya, MCP İstemcisinin, MCP Sunucusundan istemci kimliği sorması için bir kural oluşturabiliriz. Bu zor bir görev değil.

Dinamik İstemci Kaydı teoride MCP ekosistemine esneklik sağlar, ancak pratik uygulamada, bu dinamik kayıt mekanizmasına gerçekten ihtiyaç duyup duymadığımızı düşünmemiz gerekebilir. Çoğu hizmet sağlayıcısı için, OAuth İstemcisini manuel olarak oluşturmak ve yönetmek muhtemelen daha kontrol edilebilir ve güvenli bir yoldur.

Özet#

Bu makale, MCP Yetkilendirme Özelliğinin tasarım felsefesini ve uygulama zorluklarını derinlemesine analiz eder. OAuth 2.1 tabanlı bir yetkilendirme çerçevesi olarak, bu özellik, Uzaktan MCP Sunucusunun kullanıcılar adına kullanıcı kaynaklarına nasıl erişeceği sorununu çözmeyi amaçlamaktadır.

MCP Sunucusunun Yetkilendirme Sunucusu ve Kaynak Sunucusu olarak çift rollerinin yanı sıra Dinamik İstemci Kaydı ve üçüncü taraf yetkilendirme devri mekanizmalarının artıları ve eksileri ile ilgili ayrıntılı tartışma ile bu makale, Yetkilendirme uygulayıcı olarak kişisel deneyimlerden düşünceler ve öneriler sunar.

Logto ekibinin bir üyesi olarak, MCP yetkilendirme spesifikasyonunun hâlâ gelişmekte olduğunu belirtmek önemlidir. AI modelleri ve harici hizmetler arasında güvenli etkileşime katkıda bulunmak amacıyla, bu spesifikasyonun en son gelişmelerini izlemeye ve uygulama çözümlerimizi pratikte sürekli optimize etmeye devam edeceğiz.