Kimlik doğrulama, uzak MCP sunucuları için en kritik güvenlik katmanıdır. OAuth 2.1 ile OIDC’nin neden zorunlu olduğunu, token delegasyonunun Confused Deputy saldırısını nasıl önlediğini ve token passthrough’un AI entegrasyonlarındaki en tehlikeli desenlerden biri olduğunu öğrenin.
Kimlik doğrulama, bir MCP sunucusunun güçlü yeteneklerinin meşru kullanıcılar için mi yoksa saldırganlar için mi kullanılabilir olduğunu belirleyen kapı bekçisidir. Yanlış yaparsanız, diğer tüm güvenlik kontrolleri önemsiz hale gelir - e-posta, dosya ve veritabanlarına erişimi olan, kimliği doğrulanmamış veya zayıf kimlik doğrulamalı bir MCP sunucusu, diğer her şeyi ne kadar iyi sağlamlaştırmış olursanız olun kritik bir güvenlik açığıdır.
OWASP GenAI Güvenlik Projesi’nin kılavuzu, kimlik doğrulama ve yetkilendirmeyi MCP sunucuları için sekiz temel güvenlik alanından biri olarak tanımlar ve çoğu geliştiricinin varsayılan olarak uyguladığının ötesinde özel gereksinimler içerir. Bu yazı, bu gereksinimlerin neden var olduğunu ve bunların nasıl doğru şekilde uygulanacağını açıklamaktadır.
MCP sunucuları, geleneksel hizmetlerden daha karmaşık bir kimlik doğrulama ortamıyla karşı karşıyadır çünkü birden fazla sorumlu arasında aracılık ederler:
Bu ilişkilerin her biri kendi kimlik doğrulama ve yetkilendirme kontrollerini gerektirir. Herhangi bir halkadaki bir zayıflık, diğerlerini atlamak için istismar edilebilir.
Uzak MCP sunucuları için - yerel STDIO veya Unix soketleri yerine bir ağ üzerinden erişilenler - OWASP GenAI kılavuzu kesindir: OIDC ile OAuth 2.1 zorunludur, isteğe bağlı değildir.
Bu gereksinim şu nedenlerle vardır:
OAuth 2.1 açık kapsam kontrolü sağlar. Her erişim tokeni, tam olarak hangi kaynakları ve eylemleri yetkilendirdiğini bildirir. Bir MCP sunucusu, araç çağrısı sırasında sunulan tokenın o eylem için gereken belirli kapsama sahip olduğunu doğrulayabilir - sadece kullanıcının kimliğinin doğrulandığını değil, bu belirli işlem için yetkilendirildiğini.
OIDC kriptografik kimlik sağlar. OpenID Connect, MCP sunucusunun kimlik sağlayıcısına gidiş-dönüş yapmadan doğrulayabileceği kimlik iddiaları (ID token) ekler. Sunucu her istekte iss (yayıncı), aud (hedef kitle), exp (son kullanma) ve imzayı doğrular.
OAuth 2.1 tokenları tasarım gereği kısa ömürlüdür. Modern OAuth spesifikasyonu (OAuth 2.0 en iyi uygulamalarını birleştirir ve yerini alır), düzenli olarak yenilenmesi gereken kısa ömürlü erişim tokenlarını vurgular. Bu, bir token tehlikeye girerse hasar penceresini sınırlar.
Tokenları yalnızca oturum kurulumunda doğrulamayın. Her araç çağrısında doğrulayın:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Doğrulama sonuçlarını istekler arasında asla önbelleğe almayın. Oturum başlangıcında geçerli olan bir token, oturum ortasında iptal edilmiş olabilir.
MCP istemcilerinin sık sık değiştiği ortamlarda (örneğin, aynı sunucuya bağlanan farklı AI asistanları), statik API anahtarları veya önceden paylaşılan sırlar yetersizdir. Bağlantı sırasında istemci kimliğini doğrulamak için OAuth 2.1 veya OIDC ile dinamik istemci kaydı kullanın. İzin listeleri, sabit kodlanmış bağlantı politikaları veya karşılıklı TLS (mTLS), belirli istemciler ve sunucular arasındaki bilinen statik ilişkiler için uygundur.
Bugün ücretsiz denemenizi başlatın ve günler içinde sonuçları görün.
Confused Deputy, MCP mimarilerinde özellikle tehlikeli bir tezahürü olan klasik bir yetkilendirme güvenlik açığıdır. Saldırı, bir MCP sunucusunun kimin yetkisiyle hareket ettiğinin belirsizliğini istismar eder.
Bu senaryoyu düşünün:
Alice, AI asistanından “proje klasörümü özetle” dediğinde, sunucu Alice’in tokenını kullanarak dosyalarına erişir - doğru davranış. Ancak bir saldırgan, sunucuyu kendi hizmet kimlik bilgilerini kullanarak bir istekte bulunmaya kandırırsa (belki bir araç zehirleme saldırısı veya dolaylı prompt enjeksiyonu yoluyla), sunucunun yükseltilmiş izinleri Alice’in görmesine yetkili olmadığı dosyalara erişmek için kullanılır.
Sunucu “confused deputy"dir - o yetkiye sahip olmayan biri adına yetkisini kullanması için kandırılmıştır ve ayrıcalık yükseltme için bir vekil olarak hareket etmektedir.
Birçok MCP uygulaması, basitlik için istemcinin tokenını downstream API’lere iletir. Bu sezgisel görünür - kullanıcının tokeni kullanıcının izinlerini temsil eder, bu nedenle tüm downstream çağrılar için kullanmak doğru erişim kontrolünü korur.
Sorun: MCP sunucusunu güvenilir bir aracı olarak tanıyan downstream API’ler, iletilen kullanıcı tokenının seviyesi yerine sunucunun kimlik seviyesini kullanarak istekleri onaylayabilir. Ve MCP sunucusu kendi inisiyatifiyle hareket ederse - kullanıcının açıkça talep etmediği AI karar verme yoluyla - kullanıcının tokeni yerine kendi kimlik bilgilerini kullanabilir.
Kullanıcı tokenlarını iletmek ayrıca:
İstemci tokenlarını iletmek yerine, MCP sunucusu OAuth’un On-Behalf-Of (OBO) akışını kullanarak downstream hizmet erişimi için kendi tokenlarını almalıdır:
Kullanıcı MCP istemcisine kimlik doğrular → istemci kullanıcı erişim tokeni alır
MCP istemcisi kullanıcı tokenını MCP sunucusuna sunar
MCP sunucusu OBO akışı aracılığıyla kullanıcı tokenını sunucu tokeni ile değiştirir:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP sunucusu downstream çağrılar için kendi OBO tokenını kullanır
OBO tokeni:
OWASP GenAI kılavuzu belirli bir öneri yapar: erişim tokenlarını saatlerle değil, dakikalarla ölçülen ömürlerle verin. Bu, hem MCP sunucusunun istemcilerden kabul ettiği tokenlar hem de downstream hizmet erişimi için aldığı tokenlar için geçerlidir.
Çalınan bir erişim tokeni, meşru kullanıcının oturumu kapatıp kapatmadığına, şifresini değiştirip değiştirmediğine veya oturumunu iptal edip etmediğine bakılmaksızın tam ömrü boyunca geçerlidir. Bir oturumun başında çalınan 24 saatlik token, saldırgana 24 saat kalıcı erişim verir. Oturum ortasında çalınan 5 dakikalık token en fazla 5 dakika verir.
Kısa ömürlü tokenlar ayrıca düzenli yeniden kimlik doğrulama olaylarını zorlar, bu da şunlar için fırsatlar sağlar:
Her token, yalnızca gerçekleştirilen belirli işlem için gereken kapsamları taşımalıdır. Mevcut araç çağrısı yalnızca read:files gerektiriyorsa, read:files write:files delete:files kapsamına sahip bir token vermeyin. Bu, token ele geçirilirse veya model beklenmeyen araç çağrılarına manipüle edilirse hasarı sınırlar.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Aracı minimum gerekli kapsamlara eşle
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5 dakikalık ömür
)
En son ipuçlarını, trendleri ve teklifleri ücretsiz alın.
Yaygın bir hata, oturum kimliklerini yetkilendirme vekilleri olarak kullanmaktır: bir istek geçerli bir oturum kimliği taşıyorsa, sunucu bunun yetkilendirildiğini varsayar. Bu, durum yönetimini kimlik doğrulama ile karıştırır.
Doğru model: oturum kimlikleri konuşma durumunu yönetir. Yetkilendirme, OAuth tokenının iddialarını doğrulayarak her istekte bağımsız olarak doğrulanır. Geçerli bir oturum kimliği taşıyan bir istek bile, herhangi bir araç çağrısına izin verilmeden önce geçerli, süresi dolmamış, uygun şekilde kapsamlı bir OAuth tokeni sunmalıdır.
Bu önemlidir çünkü oturum kimlikleri, kriptografik bütünlük garantileri taşıyan OAuth tokenlarının yapamayacağı şekillerde çalınabilir, tahmin edilebilir veya yeniden oynatılabilir.
Yetkilendirme kontrollerini bireysel araç işleyicileri boyunca dağılmış olarak uygulamak yerine, OWASP GenAI kılavuzu şunları yapan bir merkezi politika ağ geçidi önerir:
Merkezileştirme, politikaların tüm araçlar ve ajanlar genelinde tutarlı bir şekilde uygulanmasını sağlar. Araca özgü bir yetkilendirme kontrolü unutulabilir veya geliştirme sırasında atlanabilir; bir ağ geçidi kontrolü atlanamaz.
Uzak MCP sunucuları için minimum kimlik doğrulama güvenlik çıtası:
OAuth 2.1, uzak MCP sunucuları için gereklidir çünkü açık kapsam kontrolü, kısa ömürlü tokenlar, kriptografik doğrulama ve standartlaştırılmış kimlik iddiaları (OIDC aracılığıyla) ile delegasyonlu yetkilendirme sağlar. API anahtarları veya oturum çerezleri gibi daha basit yöntemler, en az ayrıcalık erişimini uygulamak için gereken kapsam ayrıntı düzeyinden yoksundur, kriptografik kimlik garantileri sağlamaz ve bir oturum sona erdiğinde ayrıntılı olarak iptal edilmeleri zordur.
Confused Deputy, MCP sunucusunun, talep eden kullanıcının yetkili olmadığı eylemleri gerçekleştirmek için kendi (daha yüksek) ayrıcalıklarını kullanması için kandırıldığı bir ayrıcalık yükseltme saldırısıdır. Token passthrough kullanıldığında ortaya çıkar - sunucu, kullanıcının tokenını downstream API'lere iletir ve bu da kullanıcıya sunucunun güvenilir statüsüne dayanarak sahip olmaması gereken erişim izni verebilir. Çözüm, tokenların MCP sunucusunun belirli erişim kapsamı için açıkça verildiği On-Behalf-Of token akışlarını kullanmaktır.
Token passthrough, MCP sunucusunun kendi sunucu tarafından verilen kimlik bilgilerini kullanmak yerine istemcinin kimlik doğrulama tokenını doğrudan downstream API'lere iletmesi anlamına gelir. Bu tehlikelidir çünkü: (1) denetim izlerini bozar - downstream sistemler kullanıcı tokenını görür, MCP sunucusunu görmez, bu da eylemleri sunucuya atfetmeyi imkansız hale getirir; (2) MCP sunucusunun kendi erişim politikalarını atlar; (3) downstream API, MCP sunucusunun kimliğine kullanıcının kimliğinden daha fazla güveniyorsa Confused Deputy güvenlik açığı oluşturur; ve (4) MCP sunucusu tehlikeye girerse, saldırgan tüm bağlı downstream hizmetler için iletilen kullanıcı tokenlarına erişim kazanır.
OWASP GenAI kılavuzu, ömürleri saat veya günlerle değil, dakikalarla ölçülen tokenlar önerir. Daha kısa token ömürleri, bir token çalınırsa veya bir oturum ele geçirilirse istismar penceresini sınırlar. Her araç çağrısı, tokenın imzasını, hedef kitlesini ve son kullanma süresini yeniden doğrulamalıdır - oturum başlangıcındaki önbelleğe alınmış doğrulamaya güvenmemelidir.
Arshia, FlowHunt'ta bir Yapay Zeka İş Akışı Mühendisidir. Bilgisayar bilimi geçmişi ve yapay zekaya olan tutkusu ile, yapay zeka araçlarını günlük görevlere entegre eden verimli iş akışları oluşturmada uzmanlaşmıştır ve bu sayede verimlilik ile yaratıcılığı artırır.
Güvenlik ekibimiz, MCP kimlik doğrulama yapılandırmalarını, token yönetimini ve yetkilendirme akışlarını OWASP GenAI standartlarına göre değerlendirir. Saldırganlar fark etmeden önce açıkları tespit edin.
MCP sunucuları, geleneksel API risklerini yapay zekaya özgü tehditlerle birleştiren benzersiz bir saldırı yüzeyi ortaya çıkarır. OWASP GenAI tarafından tanımlan...
OWASP GenAI Güvenlik Projesi, güvenli MCP sunucu dağıtımı için beş kategorili bir minimum standart tanımlar. Üretime geçmeden önce kimlik, izolasyon, araçlar, d...
Prompt enjeksiyonu, üretim ortamındaki MCP sunucularına karşı birincil saldırı vektörüdür. OWASP tarafından önerilen dört kontrolü öğrenin: yapılandırılmış araç...