MCP OAuth 2.1 derinlemesine inceleme: metadata keşfi, PKCE ve audience'a bağlı token'lar

Kılavuzun kapsadığı konular

dev.to'da yayınlanan bir uygulayıcı kılavuzu, çoğu hızlı başlangıç rehberinin atladığı MCP yetkilendirmesinin kısımlarını ele alıyor: istemcilerin bir authorization server'ı nasıl keşfettiği, verilen token'ların tek bir belirli MCP server'a nasıl bağlandığı ve bir resource server'ın her istekte neyi doğrulaması gerektiği. Yazar, yazının yapay zeka yardımıyla yazıldığını ve doğruluk açısından incelendiğini belirtiyor.

Yazıya göre MCP yetkilendirme spesifikasyonu OAuth 2.1 üzerine inşa edilmiştir ancak uygulamaların çoğu zaman atladığı kısıtlamalar ekler. Bir MCP server tipik olarak bir OAuth resource server olarak davranır — token'ları doğrular ama onları vermez. İstemcilerin authorization server'ı hardcode edilmiş endpoint'ler yerine protected resource metadata (RFC 9728) üzerinden bulması beklenir, token'lar audience'a kısıtlı olmalıdır ki bir server için üretilen bir token aynı identity provider'ı paylaşan bir başkasına karşı kullanılamasın, ve PKCE zorunludur çünkü MCP istemcileri genellikle client secret koruyamayan CLI araçları veya masaüstü uygulamaları gibi public client'lardır.

Protected resource metadata ile keşif

İlk uygulama adımı, /.well-known/oauth-protected-resource adresinde bir JSON dokümanı sunmaktır. Bu doküman, sunucunun kendi URL'sini bir resource alanında bildirir, istemcilerin kullanması gereken authorization server'ları listeler ve desteklenen bearer yöntemlerini duyurur. Yazar, resource alanının göründüğünden daha önemli olduğunu savunuyor: sunucunun daha sonra token'ın aud claim'i ile karşılaştırdığı değer budur. Dokümanı atlamak, her istemcinin auth server'ın URL'si ile manuel yapılandırma gerektirmesi anlamına gelir; bu varsayım, kurum identity provider'larını değiştirdiği ilk anda çöker.

PKCE artı bir resource indicator

İstemci tarafında akış rastgele bir code verifier üretir, ondan bir S256 challenge türetilir ve hem challenge hem de RFC 8707 ile tanımlanan bir resource parametresi yetkilendirme isteğine dahil edilir. Yazarın çoğu eğitimin atladığını söylediği parça bu resource parametresidir — authorization server'a verilen token'a hangi audience'ın gömüleceğini söyler. Bu olmadan, auth server token'ları kaynak başına kısıtlamıyorsa, bir kullanıcının bir MCP server için onayladığı token, farklı ve muhtemelen kötü niyetli bir server tarafından da kabul edilebilir.

Bir token'a güvenmeden önce dört kontrol

Yazının merkezindeki iddia, imza doğrulamanın token doğrulama ile aynı şey olmadığıdır. Dört kontrol listeleniyor: sahte token'ları yakalayan imza veya introspection; sunucunun kendi resource URL'siyle eşleşen, sunucular arası token replay'ini yakalayan aud claim; süresi geçmiş veya henüz geçerli olmayan token'ları yakalayan exp ve nbf zaman damgaları; ve istenen araç için scope yeterliliği, ki bu da salt okunur bir token'ın kayıt silmesi gibi aşırı yetkili çağrıları yakalar.

Yazarın pratikten gözlemi, imza kontrollerinin neredeyse her zaman yapıldığı çünkü kütüphanelerin bunları hallettiği, buna karşılık audience kontrollerinin atlandığıdır — çünkü bunlar sunucunun bir resource olarak kendi kimliğini bilmesini gerektirir ki bu da ancak metadata adımı baştan düzgün yapılmışsa işe yarar.

Oturumlar token değildir

Geçerli bir token kimin çağırdığını kanıtlar; bir MCP oturumunun durumu hakkında hiçbir şey söylemez. Yazı ikisini ayrı tutmayı önerir. Token'lar kısa ömürlü olmalı, kabaca 15 ila 60 dakika, kimlik ve scope'ları taşımalı ve her istekte doğrulanmalıdır. Oturumlar, token ile birlikte gönderilen bir session ID ile anahtarlanan sunucu tarafı durumdur; konuşma ve araç çağrısı bağlamını tutar, ömrü ve boşta kalma zaman aşımı token'dan bağımsızdır. Süresi dolmuş bir token'ı yenilemek, bir agent'ın devam eden çok adımlı iş akışını sıfırlamamalıdır; buna karşılık boşta kalmış bir oturum, teknik olarak hala geçerli olsa bile token'ın yeni bir yetkilendirme handshake'i gerektirmelidir.

Pratikte görülen başarısızlık modu

Yazara göre gerçek dünyada en sık görülen arıza, eksik bir imza kontrolü değil, aynı kurumdaki birkaç MCP server için tek bir authorization server'ın token verdiği multi-tenant kurulumlardaki audience karışıklığıdır. Bir ekip imzaları ve süre sonunu doğrular, işini bitirir sayar ve aylar sonra dahili bir analitik MCP server için üretilen bir token, müşteriye dönük olanagainst da çalışır çünkü kimse aud'yi kontrol etmemiştir. Resource indicator ve audience kontrolü tam olarak bu boşluğu kapatmak için vardır.

Yazı dört soruluk bir denetimle bitiyor: doğru bir resource alanıyla well-known metadata dokümanını yayınlamak, yetkilendirme sırasında RFC 8707 resource parametresini göndermek, yalnızca imza ve süre sonu yerine aud'yi kontrol etmek ve oturumları token ömründen bağımsız olarak kendi boşta kalma zaman aşımlarıyla takip etmek.

Neden önemli

MCP server'ları giderek gerçek verilerin ve gerçek araç yürütmenin önünde duruyor ve çoğu zaman tek bir identity provider'a güvenen birkaç servis oluyor. Yazının tarif ettiği başarısızlık — bir server için doğru şekilde imzalanmış bir token'ın bir başkası tarafından kabul edilmesi — tek istemcili bir demoda asla görünmez ve yalnızca multi-tenant üretimde ortaya çıkar. Ana akım OAuth kütüphaneleri imza doğrulamayı kolaylaştırır ama audience ve scope zorlamasını uygulamaya bırakır; dolayısıyla burada vurgulanan kontroller tam olarak ekiplerin atlamaya eğilimli olduklarıdır. Token doğrulayan bir MCP server inşa eden herkes, keşfi, audience bağlamayı ve oturum/token ayrımını ciladan çok temel gereksinimler olarak görmelidir.