Inside the Harness: MCP OAuth Issuer Binding ve Protokol Güvenliğinin Neden String Karşılaştırmasına Dayandığı

Üç sayı, sonra açıklayacağım. Bir: OAuth metadata document içindeki issuer field tek bir string. İki: bu yaz Atlassian, Context7 ve Home Assistant'ın her biri, bu string'in document'ın fetch edildiği URL ile eşleşmediği MCP authorization metadata sundu ve strict client'lar bağlantıyı reddetti. Üç: MCP specification'a şimdi gelen fix özünde "string'i karşılaştır, farklıysa reddet." Bütün mekanizma bu ve kapattığı saldırı OAuth'ın en kötü sınıflarından biri: MCP'nin deploy edilme biçimiyle structural olarak daha kötü hale gelen mix-up attack.

Bu bir Inside the Harness yazısı, yani plumbing'e giriyoruz: issuer-binding problem nedir, hangi flow'ları etkiler ve 2026-07-28 specification package MCP client veya server yapan herkesten ne ister? Aynı release'teki stateless-transport change'ler headline aldı; auth hardening altı SEP aldı ama neredeyse hiç coverage almadı. Bu ters, çünkü gerçek credential tutan MCP server çalıştırıyorsanız, confused client'ın token'ı yanlış tarafa verip vermediğini belirleyen kısım bu.

Temel çıkarımlar - MCP OAuth'ın klasik şeklini tersine çeviriyor: runtime'da discover edilen birçok authorization server ile konuşan tek client. Bu ters topoloji mix-up attack'ların tam hedefi. - 2026-07-28 specification package altı SEP. En önemli ikisi: SEP-2468, authorization response içindeki iss parametresini RFC 9207'ye göre validate eder; SEP-2352, her registered client credential'ı onu mint eden issuer'a bind eder. - Bu teorik değil. Atlassian ve Context7 MCP endpoint'leri bu yaz issuer-mismatched metadata sundu, strict client'ları kırdı; spec production'da zaten var olan failure'ları yakalıyor. - iss validation bugün recommended ve mandatory olmaya gidiyor. Bugün ekleyin ve support etmesi gereken server'da missing iss durumunu shrug değil rejection olarak görün. - Tam uygulanmış olsa bile bu package sadece client-to-server authentication'ı güçlendiriyor. Agent identity, per-request authorization, delegation provenance ve audit protokol dışında, sizin sorumluluğunuzda.

Ne oldu

21 Mayıs 2026'da MCP maintainers, 2026-07-28 specification release candidate'ını lock etti, final spec 28 Temmuz'da çıktı ve SDK maintainers o zamandan beri on haftalık validation window içinde. Yorumların çoğu stateless shift'e gitti. Altında, Tigera'nın release'i yakından okumasına göre, OAuth layer'ı güçlendiren altı Spec Enhancement Proposal var:

Üç housekeeping SEP, 2207, 2350, 2351, clarification. Auth spec'teki clarification önemlidir: iki SDK metadata document'ın nerede olduğu konusunda anlaşmıyorsa bu footnote değil interop outage. Fakat load-bearing pair 2468 ve 2352, ikisi de aynı soruyla ilgili: client gerçekte hangi server ile konuştuğunu nasıl bilir?

MCP 2026-07-28 specification package altı OAuth-hardening SEP içeriyor: issuer validation (2468), issuer-bound credential (2352), Dynamic Client Registration'da client type declaration (837), ayrıca documented refresh token (2207), scope accumulation (2350), discovery behavior (2351), Tigera analizine göre. Release candidate 21 Mayıs'ta lock edildi ve final spec 28 Temmuz 2026'da çıktı.

Vulnerability model: tek client, birçok issuer

Klasik OAuth birçok client, bir authorization server varsayar: binlerce app, tek identity provider, tek token issuer. Client'ın authorization response'u yanlış server'a atfetmeye kandırıldığı mix-up attack'lar niche concern idi, çünkü çoğu client tek issuer ile konuşuyordu.

MCP bütün şekli tersine çalıştırıyor. Tek client, host application, birçok MCP server ile konuşuyor; her biri farklı authorization server arkasında olabilir, runtime'da discover edilir ve çoğu zaman Dynamic Client Registration ile on the fly register edilir. Spec authors açıkça söylüyor: issuer-validation SEP, "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern" hedefliyor, Tigera'nın yazısında alıntılandığı gibi. Client aynı anda bir düzine authorization server registration tutuyorsa attacker crypto kırmak zorunda değil. Client'ın response'u yanlış server'a atfetmesini sağlamalı.

Şekli şöyle. Agent host honest server A ile mid-flow iken, aslında attacker-controlled server B'den response geliyor. Issuer check yoksa client exchange'i B ile tamamlayıp authorization code leak edebilir veya B'nin mint ettiği token'ları kabul edip ileri sunabilir. RFC 9207, klasik OAuth için 2021 fix, authorization response'lara explicit iss parametresi ekledi, client unexpected issuer'ı reddedebilsin diye; SEP-2468 bu requirement'ı MCP'ye getiriyor. SEP-2352 daha sessiz yarıyı, credential'ları ele alıyor. Öncesinde client issuer A tarafından mint edilen client ID tutup resource issuer B'ye migrate olduğunda A'nın credential'ını B'ye sunabiliyordu. Bazen çalışıyordu ve "bazen çalışır" auth system'de istediğiniz property değil. Bu yüzden 2352 registration'ların authorization server başına tutulmasını, issuer value'ya bind edilmesini ve migration'da yeniden register edilmesini gerektiriyor.

Bu class'a ilk müdahale de değil. 2025-06-18 spec revision Resource Indicators RFC 8707'yi mandatory yaptı ki token'lar belirli bir server için mint edilsin; MCP authorization spec zaten other resource için token kabul etmeyi veya downstream pass etmeyi yasaklıyor. 2026-07-28 package aynı trajectory'yi sürdürüyor: default daha az trust, daha explicit binding. MCP versus API yazımı okuduysanız, bu orada anlattığım flexibility'nin maliyeti: runtime discovery MCP'yi composable yapıyor ve bu identity question'ları da yaratıyor.

MCP'nin one-client-many-servers topology'si mix-up attack'ların hedeflediği deployment pattern'in tam kendisi: attacker crypto'yu kırmaz, client'ın response veya credential'ı yanlış authorization server'a atfetmesini sağlar. SEP-2468 RFC 9207 iss parametresiyle response'ları issuer'a bind eder; SEP-2352 registered credential'ları issuing server'a bind eder, Tigera analizi ve RFC 9207 uyarınca.

Spec production failure'ları yakalıyor

Bunlar abstract geliyorsa değil. Issuer string bu yaz real MCP deployment'larda bozuluyor ve strict client'lar şimdiden takılıyor.

Temmuz'da opencode client kullanıcıları OAuth'ın Atlassian Rovo MCP server'da discovery sırasında fail ettiğini gördü. Protected-resource metadata doğru şekilde tenant-specific authorization server advertise ediyordu, fakat orada sunulan metadata document fetch edildiği tenant path yerine çıplak shared issuer https://auth.atlassian.com declare ediyordu. RFC 8414 section 3.3, issuer value metadata'yı retrieve etmek için kullanılan URL ile .well-known suffix hariç tam eşit olmalı der; dolayısıyla opencode strict validation doğru şekilde reddetti ve login tamamen block oldu: Atlassian tarafında live endpoint'lerde confirmed spec-compliance bug. Context7 MCP endpoint benzer bug yaşadı Haziran'da, advertised authorization server ile Clerk subdomain üzerindeki metadata issuer farklıydı ve official MCP Go SDK flow'u reddetti. Home Assistant metadata ise issuer field'ı tamamen omit etti, MCP client'ları başka şekilde bozdu.

Bu üçü mix-up exploit değildi; interoperability failure idi. Ama nokta bu. Attacker fake server'ını block eden aynı string comparison sloppy gerçek server'ı da block eder, dolayısıyla ecosystem eskiden yanlış olup yine de geçen metadata'ya çok daha az toleranslı olacak. WorkOS mix-up attacks yazısı operational point'i iyi yapıyor: birçok OAuth library RFC 9207 checking'i default off bırakıyor ve CVE-2026-59208'i, account lookup'ı confirmed issuer'a scope etmenin, sub claim'i global match etmek yerine, bug'ı tamamen durduracağı vaka olarak gösteriyor. O CVE reference'ı independent verify edilmiş değil, WorkOS reported olarak görürüm, ama defensive principle zaten standard practice.

Real MCP deployment'lar bu yaz issuer validation'da fail etti: Atlassian Rovo MCP server fetch edildiği tenant URL ile eşleşmeyen issuer metadata sunuyor (opencode issue #39332), Context7 endpoint bir authorization server advertise ederken metadata başka bir tane declare etti (Context7 issue #2723), Home Assistant issuer field'ı tamamen omit etti. RFC 8414 section 3.3 issuer value'nun retrieval URL ile tam eşleşmesini gerektiriyor, bu yüzden strict client'lar üçünü de doğru şekilde reddetti.

Implementer'lar ne yapmalı

MCP client maintain ediyorsanız:

1. Her authorization response'da iss şimdi validate edin. Mid-flow olduğunuz issuer ile mismatch'i reject edin; server RFC 9207 support advertise edip parametreyi omit ediyorsa onu da reject edin. Spec missing iss rejection'ın future version'da expected olacağını açıkça söylüyor, bugün mandatory sayın.

2. Registration state'i authorization server başına partition edin. Her client ID, secret ve refresh token onu mint eden issuer value'ya karşı saklanır. Resource protected-resource metadata yeni authorization server'a işaret etmeye başlarsa yeniden register edin; old credential replay etmeyin.

3. Dynamic Client Registration sırasında application_type declare edin. SEP-837 desktop veya CLI client'ın default web sayılıp localhost redirect URI nedeniyle reddedildiği failure class'ı kapatır. Tek field, gerçek bug class bitti.

4. Account lookup'ları issuer'a scope edin. sub claim yalnızca gerçekten validate ettiğiniz issuer namespace içindeki account'larla match olmalı. Global match etmeyin.

MCP server veya önünde authorization server işletiyorsanız: issuer değeri retrieval URL ile tam eşit metadata sunun, tenant path dahil; RFC 9728 protected-resource metadata implement edin ve token'ların sizin resource için mint edildiğini validate etmeye devam edin. Ve büyüyen MCP server listesine karşı self-hosted agent çalıştırıyorsanız, fleet math önemli: N agents x M servers = N x M issuer-bound registration. On agent ile spreadsheet, yüz agent ile registry; spec registry hakkında opinion sahibi değil. O kısım platform'unuzda.

Implementer'lar authorization response'da iss validate etmeli, mismatch ve support edildiğinde omission'ı reject etmeli, credential'ları issuer'a partition ederek saklamalı ve migration'da yeniden register olmalı, Dynamic Client Registration sırasında application_type declare etmeli ve account lookup'ları validated issuer'a scope etmeli, Tigera SEP analizine ve WorkOS mix-up guidance'a göre. Tier 1 SDK'ların spec'in on haftalık validation window'unda support ship etmesi bekleniyor.

Spec hâlâ neyi cevaplamıyor

Package'i tekrar okuyun ve altı SEP'in ortak noktasını görün: tek OAuth client ile tek authorization server arasındaki exchange'i harden ediyorlar. Yapılması gerekiyordu. Ama Tigera analizi açıkça söylüyor, token client'ı authenticate eder, agent'ı değil. Bir host arkasındaki iki yüz agent tek client identity paylaşır; issuer binding hangi agent'ın, kimin behalf'inde, neye dayanarak karar verdiği hakkında hiçbir şey söylemez. Scope admission'dır, per-request policy değil. Delegation chain, agent calls agent calls server, her hop OAuth-clean olabilir ve end-to-end unaccountable kalabilir. Package hiçbirinin yazılmasını da gerektirmiyor; protocol için doğru scoping decision, enterprise için incomplete answer.

Bunu çalışmayı küçümsemek için söylemiyorum. Issuer validation olmayan MCP, certificate checking olmayan HTTP gibiydi ve o hole kapanıyor. Ama dört gap, agent identity, per-request authorization, delegation provenance, audit, governance layer ve spec bekleyerek gelmiyor. Bunlar müşterilerle agent governance üzerinde çalıştığım aynı gaps ve agent çevresindeki environment tarafından enforce edilir ya da kimse etmez.

FAQ

MCP OAuth issuer-binding issue nedir?

MCP client'lar runtime'da discover edilen birçok authorization server ile konuşuyor, bu da mix-up attack riskini doğuruyor: response veya credential yanlış server'a atfediliyor. 2026-07-28 spec bunu client'ların authorization response iss parametresini validate etmesini, SEP-2468 ve RFC 9207, ve her registered credential'ı issuer'a bind etmesini, SEP-2352, gerektirerek kapatıyor.

Bu MCP'nin kendi vulnerability'si mi?

Protocol deployment pattern'in daha yaygın hale getirdiği vulnerability class, şimdi spec level'da kapatılıyor. Bu yaz production'da görülen Atlassian, Context7, Home Assistant issuer-mismatch metadata failure'ları implementation bug idi, fakat unvalidated model'in ne kadar fragile olduğunu gösteriyor. Strict validation artık baseline.

Hangi flow'lar etkileniyor?

Birden fazla authorization server'a registered client'lı authorization-code flow'lar, server'lar arası Dynamic Client Registration, resource authorization server arasında migrate olduktan sonra credential use, .well-known document ile metadata discovery. Single-server deployment risk değildi; agents'ın yarattığı multi-server topology risk.

Ne zaman mandatory oluyor?

2026-07-28 spec final, SDK support Mayıs release-candidate lock'tan on haftalık validation window içinde geliyor ve spec future version'da iss olmayan response'ların rejection'ını expected diye açık söylüyor. Bugün yaptığınız her şeyde mandatory kabul edin.

Sonuç

OAuth security çoğunlukla consequence taşıyan sıkıcı string comparison ve MCP bu gerçekle hesaplaştı. 2026-07-28 package beş yıllık OAuth fix'i, one-client-many-servers şekli onu urgent hale getiren protocol'e getiriyor, tam real deployment'lar field'da bu check'te fail olmaya başladığı sırada. SDK'ları update edin, iss validate edin, registration'ları bind edin. Sonra spec'in doğru olarak cevaplamadığı soruyu sorun: sizin mint ettiğiniz token asla onaylamayacağınız tool call için kullanıldığında, ismini veremediğiniz agent tarafından sunulduğunda, bunu kim yakalıyor ve record nerede? Cevap specification'dan gelmiyor. Etrafına kurduğunuz harness'tan geliyor.

MCP deployment için auth ve identity'yi çözüyorsanız, bu müşterilerle düzenli konuştuğum konu. İletişime geçin.

Kaynaklar

• Tigera, "MCP's Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don't": https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (yayımlanma 2026-07-28, erişim 2026-08-29)

• WorkOS, "OAuth mix-up attacks and RFC 9207: The issuer check that never made it to token exchange": https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (yayımlanma 2026-07-20, erişim 2026-08-29)

• Model Context Protocol, Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (yayımlanma 2025-11-25, erişim 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification": https://www.rfc-editor.org/rfc/rfc9207.html (yayımlanma 2021-12-16, erişim 2026-08-29)

• opencode repository, issue #39332, "MCP OAuth: Atlassian auth fails - RFC 8414 issuer mismatch": https://github.com/anomalyco/opencode/issues/39332 (yayımlanma 2026-07-28, erişim 2026-08-29)

• Context7 repository, issue #2723, "OAuth metadata issuer mismatch for MCP OAuth endpoint": https://github.com/upstash/context7/issues/2723 (yayımlanma 2026-06-05, erişim 2026-08-29)

• Home Assistant Core, issue #147059, missing issuer in OAuth metadata: https://github.com/home-assistant/core/issues/147059 (yayımlanma 2025-06-17, erişim 2026-08-29)

• modelcontextprotocol/modelcontextprotocol repository: https://github.com/modelcontextprotocol/modelcontextprotocol (erişim 2026-08-29)