MCP Authorization 2026: Kenapa DCR Mulai Ditinggalkan

Ada kalimat yang berbahaya kalau dipotong terlalu pendek: “DCR deprecated.”

Orang yang baru membaca MCP 2026-07-28 bisa langsung menyimpulkan Dynamic Client Registration sudah tidak boleh dipakai. Itu tidak akurat.

Status resminya lebih nuanced. Dalam MCP 2026-07-28, Dynamic Client Registration atau DCR memang secara formal masuk daftar deprecated, dengan Client ID Metadata Documents atau CIMD sebagai migration path. Tetapi deprecated bukan removed. Existing implementation masih dapat bekerja, dan registry deprecation MCP memberi earliest removal pada revision yang dirilis pada atau setelah 28 Juli 2027. Removal aktual tetap merupakan keputusan maintainer saat release preparation.

Jadi Agustus 2026 adalah masa transisi, bukan switch-off day.

Kenapa protocol memilih bergerak menjauh dari DCR? Untuk memahami jawabannya, kita perlu melihat problem yang ingin diselesaikan authorization MCP.

Remote MCP itu bukan sekadar API key

Bayangkan user memasang client AI yang ingin terhubung ke MCP server perusahaan. Server punya data customer, dokumen internal, atau action yang bisa mengubah record.

User tidak seharusnya memberi password perusahaan langsung ke client. MCP juga tidak ingin menciptakan authentication scheme proprietary untuk setiap server.

Karena itu authorization MCP dibangun di atas pola OAuth 2.1 dan metadata discovery.

Client menemukan Protected Resource Metadata dari MCP server, mengetahui authorization server yang relevan, membaca metadata authorization server, lalu memperoleh client identity dan menjalankan authorization flow.

Di sinilah pertanyaan besar muncul: bagaimana client yang belum punya hubungan sebelumnya dengan authorization server memperoleh client_id?

Secara historis, DCR menawarkan jawaban yang masuk akal: client mendaftar secara runtime ke registration endpoint, mengirim metadata seperti nama aplikasi dan redirect URI, lalu authorization server mengeluarkan registration information.

Kedengarannya convenient.

Tapi convenience punya operational cost.

DCR membuat authorization server harus menjadi pabrik client registration

Skenario ilustratif di tim IAM:

“Client apa ini?” tanya security engineer saat melihat daftar registration.

“Kayaknya desktop AI client.”

“Siapa owner-nya?”

“Enggak tahu, dia register otomatis.”

“Masih aktif?”

“Belum tahu.”

Itu salah satu problem governance DCR pada skala besar.

Kalau setiap client bisa mendaftarkan dirinya secara dinamis, authorization server harus menangani lifecycle registration: create, validation, redirect URI rules, credential issuance, possible rotation, cleanup, abuse control, dan audit.

Dalam environment enterprise, jumlah client registration bisa tumbuh cepat. Beberapa authorization server mendukung DCR dengan baik. Yang lain membatasinya. Ada juga organisasi yang sengaja menonaktifkannya karena governance policy.

CIMD mengambil arah berbeda.

Client ID sebagai metadata document

Client ID Metadata Documents menggunakan URL HTTPS sebagai client identifier yang mengarah ke metadata client. Alih-alih authorization server membuat registration record baru untuk setiap client yang datang, client dapat membawa identifier yang metadata-nya bisa diambil dan diverifikasi dari lokasi yang dikontrol client.

Mental model-nya berubah dari “tolong register saya sekarang” menjadi “ini identitas metadata saya, silakan resolve dan validasi”.

Itu lebih dekat dengan web-native discovery.

Bagi developer, benefit utamanya adalah mengurangi ketergantungan pada registration endpoint dan mengurangi state registration yang harus dikelola authorization server untuk hubungan yang belum pernah ada sebelumnya.

Bagi enterprise, ini berpotensi membuat client identity lebih portable dan auditable karena metadata berada pada identifier yang stabil, bukan hanya hasil registration runtime yang tersimpan di server tertentu.

Tetapi jangan romantisasi CIMD. Ia juga punya requirement security.

URL client identifier harus diperlakukan serius.
Metadata harus diambil secara aman.
Redirect URI harus tervalidasi.
Domain control penting.
Caching dan freshness metadata perlu dipikirkan.
SSRF-style concerns pada metadata retrieval perlu ditangani oleh implementasi yang aman.

Protocol yang lebih web-native tidak otomatis berarti bebas risiko.

Kenapa DCR belum langsung dihapus

Interoperability ecosystem tidak bisa bergerak dengan cara “kami prefer yang baru, jadi yang lama mati hari ini”.

Banyak MCP client dan authorization server sudah dibangun dengan DCR. Enterprise identity platform juga punya capability dan policy berbeda-beda.

Karena itu MCP memakai deprecation lifecycle.

Dalam registry 2026-07-28, DCR masih merupakan fitur specification tetapi new implementation seharusnya tidak mengadopsinya sebagai default baru. Existing implementation disarankan bermigrasi sebelum earliest removal.

Ini perbedaan penting.

Deprecated berarti arah masa depan sudah jelas.

Removed berarti protocol tidak lagi mendefinisikan feature tersebut.

Kalau tim security mengatakan “DCR masih jalan, berarti aman dipakai selamanya”, mereka mengabaikan lifecycle.

Kalau tim engineering mengatakan “DCR deprecated, harus kita cabut malam ini”, mereka juga salah membaca lifecycle.

Migration harus terencana.

MCP 2026 juga memperkeras detail authorization lain

Fokus pada DCR jangan membuat kita melewatkan perubahan security lain di revision 2026-07-28.

Authorization server dianjurkan mengembalikan parameter iss sesuai RFC 9207, dan client wajib memvalidasi issuer yang hadir sebelum menukar authorization code. Tujuannya menutup kelas authorization-server mix-up.

Client credential juga harus dibind ke issuer yang menerbitkannya. Credential tidak boleh begitu saja digunakan ulang ke authorization server lain.

Untuk DCR yang masih digunakan selama masa transisi, client perlu mengirim application_type yang tepat. Ini penting untuk aplikasi native seperti desktop atau CLI agar redirect localhost diperlakukan sesuai aturan yang benar.

Artinya pesan besarnya bukan cuma “DCR pergi”.

MCP authorization sedang bergerak makin dekat ke disiplin OAuth dan OpenID Connect yang sudah matang, termasuk discovery, issuer binding, redirect rules, dan explicit client metadata.

Apa artinya untuk product manager

Kalau Anda bukan IAM engineer, topik ini tetap punya dampak produk.

Pertama, “Connect to MCP” bukan tombol teknis sederhana.

Flow-nya melibatkan trust antara user, client, MCP server, dan authorization server. Friction pada salah satu titik bisa menjadi user experience problem.

Kedua, pilihan registration approach memengaruhi compatibility.

Client yang hanya mendukung CIMD mungkin kesulitan dengan infrastructure lama. Server ecosystem tertentu mungkin masih mengandalkan DCR. Enterprise tertentu mungkin memakai pre-registration karena hubungan antar-sistem memang sudah diketahui.

Ketiga, error message harus manusiawi.

“invalid_client” tidak membantu user bisnis.

UI sebaiknya bisa membedakan: client belum terdaftar, metadata tidak dapat diverifikasi, redirect URI tidak valid, authorization server tidak mendukung mekanisme yang diperlukan, atau administrator melarang connection.

Agentic experience yang baik tidak menyembunyikan IAM complexity, tetapi menerjemahkannya menjadi langkah yang bisa ditindaklanjuti.

Tiga pendekatan client registration jangan dicampur

Dalam evolusi authorization MCP, secara konseptual ada tiga jalur yang perlu dipahami.

Pre-registration cocok ketika client dan authorization server sudah punya hubungan. Contoh: internal enterprise agent yang dikelola tim IT dan hanya terhubung ke MCP server perusahaan.

CIMD cocok untuk client yang tidak punya hubungan sebelumnya dan ingin membawa metadata identity yang dapat ditemukan melalui identifier berbasis URL.

DCR tetap relevan untuk backward compatibility selama masa transisi atau environment yang memang membutuhkannya, tetapi status deprecated berarti jangan menjadikannya fondasi baru tanpa alasan kuat.

Tidak ada satu mekanisme yang harus dipakai untuk semua scenario.

Yang berubah adalah priority direction.

Untuk tim yang mulai membangun sekarang, pertanyaan default seharusnya bukan lagi “registration endpoint DCR kita di mana?”

Tanyakan dulu apakah CIMD bisa memenuhi use case.

Audit yang perlu dilakukan organisasi

Mulai dengan inventory.

Client mana yang menggunakan DCR?
Authorization server mana yang menyediakan registration endpoint?
Registration berapa banyak yang aktif?
Apakah ada registration orphaned?
Apakah client credential disimpan dengan issuer binding yang benar?
Apakah native app memakai application_type sesuai?
Apakah redirect URI policy aman?
Apakah logs cukup untuk menelusuri siapa mendaftarkan client?

Lalu buat migration matrix.

Client A sudah mendukung CIMD.
Client B belum.
Authorization server X mendukung metadata flow baru.
Authorization server Y masih bergantung DCR.
Internal tool Z bisa dipre-register.

Dari situ migration bisa bertahap, bukan big bang.

Untuk organisasi yang punya banyak product team, central IAM guidance sangat membantu. Jangan biarkan setiap squad membaca spec dan membuat interpretasi sendiri tentang client identity.

DCR deprecation adalah governance event, bukan cuma SDK event.

Jangan salah mengira client metadata sebagai trust otomatis

Ini juga perlu ditegaskan.

CIMD membuat metadata client discoverable dan memberi cara standar untuk menyatakan identitas serta redirect configuration. Itu bukan sertifikat bahwa client baik, aman, atau layak memperoleh semua scope.

Authorization server dan resource server tetap perlu policy.

Siapa publisher client?
Domain-nya siapa?
Scope apa yang diminta?
Apakah user boleh memberikan consent?
Apakah administrator harus approve?
Apakah client masuk allowlist?
Apa risk profile action yang akan dilakukan?

Metadata memperjelas identity surface. Trust tetap keputusan policy.

Hal yang sama berlaku untuk DCR. Fakta bahwa authorization server berhasil mendaftarkan client tidak berarti client otomatis trustworthy.

Registration dan authorization adalah dua layer berbeda.

Di agentic system, distinction ini semakin penting karena satu client bisa meminta akses ke tool yang mampu melakukan action nyata.

Scope jangan jadi formalitas

MCP server yang mengakses email, database, file, atau administrative action seharusnya tidak meminta scope lebar hanya agar development lebih cepat.

Least privilege tetap prinsip dasar.

Kalau client hanya butuh read access, jangan beri write.
Kalau tool hanya perlu satu resource family, jangan beri seluruh account.
Kalau high-impact action jarang dipakai, pertimbangkan step-up atau confirmation yang tepat.

DCR versus CIMD tidak menyelesaikan scope design.

Itu sebabnya artikel tentang authorization tidak boleh berhenti di cara mendapatkan client_id.

Client identity hanya pintu masuk. Pertanyaan besarnya tetap: setelah kita tahu siapa client-nya, apa yang boleh dia lakukan atas nama siapa, terhadap resource apa, dalam kondisi apa?

MCP 2026-07-28 memberi arah yang lebih jelas: DCR secara formal mulai keluar dari jalur utama, CIMD menjadi migration path, dan authorization makin dirapikan mengikuti web security standards.

Buat tim produk dan engineering Indonesia, respons yang tepat bukan panik dan bukan cuek.

Kalau sedang membangun baru, jangan memilih DCR hanya karena tutorial lama paling mudah ditemukan.

Kalau sudah production dengan DCR, jangan cabut tanpa compatibility plan.

Kalau bekerja di enterprise, koordinasikan dengan IAM team karena perubahan ini menyentuh registry, metadata hosting, issuer, redirect policy, client lifecycle, dan audit.

Protocol maturity sering terlihat membosankan. Banyak metadata, banyak validation, banyak edge case.

Tetapi justru di situ bedanya demo agent dengan infrastructure yang layak dipakai organisasi.

Agent boleh terasa effortless bagi user.

Authorization di belakangnya tidak boleh effortless dalam arti sembrono.