Inside the Harness: OAuth Issuer Binding MCP dan Mengapa Keamanan Protokol Hidup dari Perbandingan String

Tiga angka, lalu saya jelaskan. Satu: field issuer dalam dokumen metadata OAuth adalah satu string. Dua: musim panas ini Atlassian, Context7, dan Home Assistant masing-masing menyajikan metadata authorization MCP di mana string itu tidak cocok dengan URL tempat dokumen diambil, dan client yang strict menolak koneksi. Tiga: perbaikan yang sekarang masuk ke spesifikasi MCP, pada intinya, adalah "bandingkan string, tolak jika berbeda". Itu seluruh mekanismenya, dan attack yang ditutupnya adalah salah satu yang paling buruk di OAuth: mix-up attack, dibuat secara struktural lebih berbahaya oleh cara MCP di-deploy.

Ini tulisan Inside the Harness, jadi kita masuk ke plumbing: apa masalah issuer binding, flow mana yang terdampak, dan apa yang diwajibkan paket spesifikasi 2026-07-28 kepada siapa pun yang membangun client atau server MCP. Perubahan stateless transport dalam release yang sama mendapat headline; auth hardening mendapat enam SEP dan hampir tidak ada coverage. Itu terbalik, karena jika Anda menjalankan server MCP dengan credential nyata, bagian inilah yang menentukan apakah client yang bingung menyerahkan token ke pihak yang salah.

Poin utama - MCP membalik bentuk klasik OAuth: satu client berbicara ke banyak authorization server yang ditemukan saat runtime. Pembalikan itu tepat merupakan topologi yang ditarget mix-up attack. - Paket spesifikasi 2026-07-28 berisi enam SEP. Dua yang paling penting: SEP-2468, validasi parameter iss pada authorization response sesuai RFC 9207, dan SEP-2352, mengikat setiap client credential terdaftar ke issuer yang menerbitkannya. - Ini bukan teori. Endpoint MCP Atlassian dan Context7 telah menyajikan metadata dengan issuer mismatch musim panas ini dan merusak client strict; spesifikasi sedang mengejar kegagalan yang sudah ada di production. - Validasi iss direkomendasikan sekarang dan bergerak menuju wajib. Bangun hari ini dan perlakukan iss yang hilang dari server yang seharusnya mendukungnya sebagai rejection, bukan pengabaian. - Bahkan jika sepenuhnya diadopsi, paket ini hanya memperkeras autentikasi client-to-server. Agent identity, authorization per request, delegation provenance, dan audit tetap di luar protokol, tanggung jawab Anda.

Apa yang terjadi

Pada 21 Mei 2026, maintainer MCP mengunci release candidate untuk spesifikasi 2026-07-28, spesifikasi final dirilis 28 Juli, dan maintainer SDK berada dalam validation window sepuluh minggu sejak itu. Sebagian besar komentar menuju perubahan stateless. Di bawahnya, menurut pembacaan mendalam Tigera, ada paket enam Spec Enhancement Proposal yang memperkeras layer OAuth:

Tiga SEP housekeeping, 2207, 2350, 2351, adalah klarifikasi, dan klarifikasi dalam auth spec penting: dua SDK berbeda pendapat tentang lokasi dokumen metadata adalah outage interoperabilitas, bukan catatan kaki. Tetapi pasangan load-bearing adalah 2468 dan 2352, keduanya tentang pertanyaan yang sama: bagaimana client tahu server mana yang sebenarnya sedang diajak bicara?

Paket spesifikasi MCP 2026-07-28 berisi enam SEP untuk OAuth hardening: issuer validation (2468), credential terikat issuer (2352), deklarasi tipe client dalam Dynamic Client Registration (837), plus refresh token terdokumentasi (2207), akumulasi scope (2350), dan perilaku discovery (2351), menurut analisis Tigera. Release candidate dikunci 21 Mei dan spesifikasi final dirilis 28 Juli 2026.

Model vulnerability: satu client, banyak issuer

OAuth klasik mengasumsikan banyak client, satu authorization server: ribuan app, satu identity provider, satu token issuer. Mix-up attack, ketika client ditipu untuk mengatribusikan authorization response ke server yang salah, dulu concern niche karena sebagian besar client hanya pernah berbicara dengan satu issuer.

MCP membalik semuanya. Satu client, host application, berbicara dengan banyak server MCP, masing-masing mungkin berada di depan authorization server berbeda, ditemukan saat runtime, dan sering didaftarkan on the fly via Dynamic Client Registration. Penulis spec mengatakan langsung: SEP issuer validation menarget "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", seperti dikutip tulisan Tigera. Ketika client Anda memegang registration dengan belasan authorization server sekaligus, attacker tidak perlu memecahkan crypto. Mereka hanya perlu membuat client mengatribusikan response ke server yang salah.

Bentuknya seperti ini. Host agent Anda sedang di tengah flow dengan server jujur A ketika response tiba yang sebenarnya dari server B milik attacker. Tanpa issuer check, client dapat menyelesaikan exchange melawan B, membocorkan authorization code, atau menerima token yang diterbitkan B dan meneruskannya. RFC 9207, perbaikan 2021 untuk OAuth klasik, menambahkan parameter eksplisit iss pada authorization response agar client dapat menolak apa pun dari issuer tak terduga, dan SEP-2468 membawa requirement itu ke MCP. SEP-2352 menangani setengah yang lebih sunyi: credential. Sebelumnya, client bisa memegang client ID yang diterbitkan issuer A dan, ketika resource berpindah ke issuer B, menyajikan credential A ke B. Kadang berhasil, dan "kadang berhasil" bukan properti yang Anda inginkan dalam sistem auth. Jadi 2352 mewajibkan registration disimpan per authorization server, terikat pada nilai issuer, dan daftar ulang saat migrasi.

Ini juga bukan usaha pertama terhadap kelas ini. Revisi spec 2025-06-18 membuat Resource Indicators RFC 8707 wajib agar token diterbitkan untuk satu server spesifik, dan spesifikasi authorization MCP sudah melarang menerima token untuk resource lain atau meneruskannya downstream. Paket 2026-07-28 melanjutkan arah yang sama: kurang trust by default, lebih explicit binding. Jika Anda membaca tulisan saya MCP versus API, ini adalah biaya dari fleksibilitas yang saya jelaskan: runtime discovery membuat MCP composable dan sekaligus menciptakan pertanyaan identity ini.

Topologi one-client-many-servers MCP tepat merupakan deployment pattern yang ditarget mix-up attack: attacker tidak memecahkan crypto, mereka membuat client mengatribusikan response atau credential ke authorization server yang salah. SEP-2468 mengikat response ke issuer lewat parameter iss RFC 9207; SEP-2352 mengikat credential terdaftar ke server penerbit, menurut analisis Tigera dan RFC 9207.

Spesifikasi sedang mengejar failure production

Jika semuanya terdengar abstrak, tidak. String issuer telah gagal dalam deployment MCP nyata sepanjang musim panas, dan client strict sudah tersandung.

Pada Juli, pengguna client opencode menemukan OAuth ke server MCP Rovo Atlassian gagal saat discovery. Protected-resource metadata secara benar mengiklankan authorization server spesifik tenant, tetapi dokumen metadata di sana mendeklarasikan issuer shared polos https://auth.atlassian.com alih-alih tenant path tempat ia diambil. RFC 8414 section 3.3 mengatakan nilai issuer harus tepat sama dengan URL yang digunakan mengambil metadata, dikurangi sufiks .well-known, jadi validasi strict opencode dengan benar menolak dan login terblokir penuh: bug compliance spec di sisi Atlassian, dikonfirmasi terhadap endpoint live. Endpoint MCP Context7 terkena bug serupa pada Juni, ketika authorization server yang diiklankan dan metadata issuer pada subdomain Clerk berbeda, dan MCP Go SDK resmi menolak flow. Metadata Home Assistant menghilangkan field issuer sepenuhnya, merusak client MCP dengan cara berbeda.

Tidak satu pun dari ketiganya mix-up exploit; itu failure interoperabilitas. Tetapi itulah intinya. Perbandingan string yang sama yang memblokir fake server attacker juga memblokir server asli yang ceroboh, jadi ecosystem akan jauh kurang toleran terhadap metadata yang memang selalu salah dan dulu lolos. Tulisan WorkOS tentang mix-up attack membuat poin operasional dengan baik: banyak OAuth library masih mematikan RFC 9207 check secara default, dan menunjuk CVE-2026-59208 sebagai kasus ketika membatasi account lookup ke issuer yang dikonfirmasi, bukan match claim sub secara global, akan menghentikan bug. Saya akan memperlakukan referensi CVE itu sebagai dilaporkan WorkOS, bukan diverifikasi independen, tetapi prinsip defensif tetap praktik standar.

Deployment MCP nyata gagal issuer validation sepanjang musim panas: server MCP Rovo Atlassian menyajikan metadata yang issuer-nya tidak cocok dengan URL tenant tempat diambil (opencode issue #39332), endpoint Context7 mengiklankan satu authorization server sementara metadata mendeklarasikan yang lain (Context7 issue #2723), dan Home Assistant menghilangkan field issuer sepenuhnya. RFC 8414 section 3.3 mewajibkan issuer tepat sama dengan retrieval URL, jadi client strict dengan benar menolak ketiganya.

Apa yang harus dilakukan implementer

Jika Anda memelihara client MCP:

1. Validasi iss pada setiap authorization response sekarang. Tolak mismatch dengan issuer yang sedang menjadi flow Anda, dan jika server mengiklankan dukungan RFC 9207 tetapi parameter hilang, tolak juga. Spec eksplisit bahwa rejection untuk iss hilang akan datang pada versi berikut, jadi perlakukan wajib hari ini.

2. Partisi registration state per authorization server. Setiap client ID, secret, dan refresh token disimpan melawan nilai issuer yang menerbitkannya. Jika protected-resource metadata suatu resource mulai menunjuk authorization server baru, daftar ulang; jangan pernah replay credential lama.

3. Deklarasikan application_type saat Dynamic Client Registration. SEP-837 memperbaiki kelas failure ketika client desktop atau CLI default menjadi web dan ditolak karena localhost redirect URI. Satu field, kelas bug nyata hilang.

4. Scope account lookup ke issuer. Claim sub hanya boleh match account dalam namespace issuer yang benar-benar Anda validasi. Jangan pernah match global.

Jika Anda menjalankan server MCP atau authorization server di depannya: sajikan metadata dengan issuer tepat sama dengan URL tempat ia diambil, tenant path termasuk, implementasikan protected-resource metadata menurut RFC 9728, dan terus validasi token diterbitkan khusus untuk resource Anda. Dan jika Anda self-hosting agents terhadap daftar server MCP yang bertambah, matematika fleet penting: N agent kali M server berarti N kali M registration terikat issuer. Dengan sepuluh agent itu spreadsheet; dengan seratus itu registry, dan spec tidak punya opini tentang registry. Bagian itu milik platform Anda.

Implementer harus memvalidasi iss pada authorization response, menolak mismatch dan, jika didukung, omission, menyimpan credential dipartisi berdasarkan issuer dan daftar ulang saat migrasi, mendeklarasikan application_type saat Dynamic Client Registration, dan membatasi account lookup ke issuer yang divalidasi, menurut analisis SEP Tigera dan panduan mix-up WorkOS. SDK Tier 1 diharapkan mengirim dukungan dalam validation window sepuluh minggu spesifikasi.

Apa yang belum dijawab spesifikasi

Baca paket lagi dan lihat kesamaan semua enam SEP: semuanya memperkeras exchange antara satu OAuth client dan satu authorization server. Itu perlu. Tetapi seperti dikatakan jelas dalam analisis Tigera, token mengautentikasi client, bukan agent. Dua ratus agent di belakang satu host berbagi satu client identity; issuer binding tidak berkata agent mana, atas nama siapa, memutus berdasarkan apa, berada di belakang client. Scope adalah admission, bukan policy per request. Delegation chain, agent memanggil agent memanggil server, dapat OAuth-clean di setiap hop dan tetap tanpa accountability end-to-end. Dan tidak ada di paket yang mewajibkan siapa pun menulis semuanya, keputusan scope yang benar untuk protokol tetapi jawaban tidak lengkap untuk enterprise.

Saya tidak mengatakan itu untuk mengecilkan kerja. MCP tanpa issuer validation seperti HTTP tanpa certificate checking, dan lubang itu sedang ditutup. Tetapi empat gap, agent identity, per-request authorization, delegation provenance, audit, adalah layer governance dan tidak datang hanya dengan menunggu spec. Itu gap yang sama yang saya kerjakan dengan klien dalam agent governance, dan ditegakkan environment di sekitar agent atau tidak oleh siapa pun.

FAQ

Apa masalah OAuth issuer binding di MCP?

Client MCP berbicara dengan banyak authorization server yang ditemukan saat runtime, membuat mereka rentan pada mix-up attack: response atau credential diatribusikan ke server salah. Spec 2026-07-28 memperbaiki dengan mewajibkan client memvalidasi parameter iss pada authorization response, SEP-2468 yang mengadopsi RFC 9207, dan mengikat setiap credential terdaftar ke issuer, SEP-2352.

Apakah ini vulnerability di MCP sendiri?

Ini kelas vulnerability yang deployment pattern protokol membuat lebih umum, sekarang ditutup pada level spec. Failure yang terlihat di production musim panas ini, Atlassian, Context7, Home Assistant menyajikan metadata issuer mismatch, adalah bug implementasi, tetapi menunjukkan betapa rapuh model tanpa validasi. Validasi strict sekarang baseline.

Flow mana yang terdampak?

Authorization-code flow dengan client yang terdaftar terhadap lebih dari satu authorization server, Dynamic Client Registration lintas server, penggunaan credential setelah resource migrasi antar authorization server, dan metadata discovery melalui dokumen .well-known. Deployment single-server tidak pernah menjadi risiko; topologi multi-server yang dibuat agent adalah risikonya.

Kapan menjadi wajib?

Spec 2026-07-28 final, dukungan SDK sedang masuk dalam validation window sepuluh minggu sejak release-candidate lock Mei, dan spec eksplisit bahwa menolak response tanpa iss akan diharapkan di versi berikut. Perlakukan wajib untuk apa pun yang Anda bangun sekarang.

Kesimpulan

Keamanan OAuth sebagian besar adalah perbandingan string membosankan dengan konsekuensi, dan MCP baru saja menghadapi fakta itu. Paket 2026-07-28 membawa perbaikan OAuth berusia lima tahun ke protokol yang bentuk one-client-many-servers membuatnya mendesak, tepat ketika deployment nyata mulai gagal pada check itu di lapangan. Update SDK, validasi iss, bind registration. Lalu ajukan pertanyaan yang spec benar untuk tidak jawab: ketika token yang Anda terbitkan digunakan untuk tool call yang tidak pernah Anda setujui, dibawa oleh agent yang tidak bisa Anda namai, siapa menangkapnya dan di mana record-nya? Jawaban itu tidak datang dari spesifikasi. Datang dari harness yang Anda bangun di sekelilingnya.

Jika Anda sedang mengatur auth dan identity untuk deployment MCP, itu percakapan yang rutin saya lakukan dengan klien. Hubungi saya.

Sumber

• 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/ (diterbitkan 2026-07-28, diakses 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 (diterbitkan 2026-07-20, diakses 2026-08-29)

• Model Context Protocol, Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (diterbitkan 2025-11-25, diakses 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification": https://www.rfc-editor.org/rfc/rfc9207.html (diterbitkan 2021-12-16, diakses 2026-08-29)

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

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

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

• modelcontextprotocol/modelcontextprotocol repository: https://github.com/modelcontextprotocol/modelcontextprotocol (diakses 2026-08-29)