MCP OAuth: Why Authentication for AI Agents Is Hard

Model Context Protocol awalnya sederhana. Sebuah server lokal berjalan di mesin Anda lewat stdio, berbicara dengan satu klien, dan memercayai siapa pun yang menjalankannya. Tidak ada login, tidak ada token, tidak ada OAuth. Lalu MCP menumbuhkan transport remote lewat HTTP, dan segala hal tentang identitas berubah sekaligus.

Server MCP remote berada di internet publik dan bisa dijangkau siapa pun yang tahu URL-nya. Karena itu spesifikasi otorisasi MCP mengadopsi kerangka berbasis OAuth 2.1 untuk melindunginya. Di atas kertas itu pilihan yang bertanggung jawab. Dalam praktik, memasangnya adalah salah satu pekerjaan paling menyakitkan yang akan dihadapi developer tahun ini, dan penting memahami persis kenapa.

Kenapa MCP Remote Butuh Auth

Server stdio lokal tidak butuh otorisasi karena sistem operasi sudah menyediakannya. Proses berjalan sebagai Anda, membaca kredensial dari environment variable, dan tidak bisa dijangkau lewat jaringan. Spesifikasi MCP bahkan menyebut implementasi stdio sebaiknya tidak mengikuti alur otorisasi dan cukup mengambil rahasia dari environment.

Server HTTP remote tidak punya jaminan itu. Ia adalah endpoint publik yang harus memutuskan, di setiap permintaan, siapa yang memanggil dan apakah mereka boleh masuk. Itulah persoalan klasik yang dibangun oleh OAuth: membiarkan pihak ketiga bertindak atas nama pengguna tanpa pernah melihat kata sandinya, memakai access token yang terbatas.

• Server stdio lokal mewarisi kepercayaan dari OS dan pengguna yang menjalankannya, sehingga tidak perlu pertukaran token.
• Server remote adalah endpoint publik, sehingga setiap permintaan harus membawa access token yang bisa diverifikasi.
• MCP memodelkan server remote sebagai protected resource OAuth, sehingga otorisasi menjadi bagian inti dari transport.

Apa yang Diwajibkan OAuth 2.1

Spesifikasi otorisasi MCP tidak menciptakan skema baru. Ia bersandar pada draf OAuth 2.1, ditambah standar metadata, registrasi, dan resource indicator di sekitarnya. OAuth 2.1 pada dasarnya adalah OAuth 2.0 dengan bagian yang tidak aman dibuang: implicit grant hilang, password grant hilang, dan PKCE berubah dari opsional menjadi wajib untuk setiap alur authorization code.

PKCE berarti klien membuat verifier rahasia dan challenge turunannya, mengirim challenge saat meminta authorization code, lalu membuktikan ia memegang verifier saat menukar code itu dengan token. Ini menghentikan penyerang yang menyadap code agar tidak bisa memakainya. Bagi manusia yang mengeklik lewat browser, ini pipa yang tak terlihat. Bagi agent otonom tanpa manusia di keyboard, setiap langkah ini harus diimplementasikan dengan benar dalam kode, tanpa UI sebagai cadangan.

Bagian yang Benar-benar Sulit

Kesulitannya bukan pada satu syarat pun. Melainkan karena beberapa standar asing harus bekerja bersama, dan tiap standar menambah langkah yang biasanya menuntut kehadiran manusia. Berikut bagian-bagian yang paling sering menjegal developer saat pertama kali menegakkan server MCP remote.

• Dynamic client registration: agent bisa bertemu server yang belum pernah dilihat, jadi ia harus mendaftar sendiri dan memperoleh client ID tanpa manusia mengisi formulir, memakai RFC 7591.
• Penemuan dan metadata: klien menerima 401, membaca header WWW-Authenticate, mengambil protected resource metadata, lalu mengambil authorization server metadata hanya untuk tahu ke mana mengarahkan pengguna.
• Audience token dan RFC 8707: klien harus mengirim parameter resource yang menyebut server persisnya, dan server harus menolak token yang tidak diterbitkan khusus untuknya, atau satu token bocor menjadi kunci induk.
• Perubahan spesifikasi dan persetujuan non-manusia: spesifikasi otorisasi terbit dalam revisi bertanggal yang mengubah syarat nyata, dan layar persetujuan mengasumsikan ada manusia yang menyetujui, sesuatu yang tak dimiliki agent.

Cara Melakukannya dengan Waras

Keputusan paling berguna adalah tidak membuat authorization server sendiri. OAuth adalah ranjau penuh bug keamanan halus, dan spesifikasi MCP secara eksplisit memperlakukan authorization server sebagai urusan terpisah dari resource server. Delegasikan identitas ke penyedia sungguhan, entah platform identitas terkelola atau sistem login mapan Anda sendiri, dan biarkan ia menerbitkan serta memvalidasi token.

Lalu jaga perannya tetap bersih. Server MCP Anda hanyalah resource server: ia menerbitkan protected resource metadata, menunjuk ke authorization server, dan memvalidasi bahwa setiap token masuk menyebut dirinya sebagai audience. Ia tak pernah melihat kata sandi dan tak pernah menerbitkan token. Pemisahan ini persis yang digambarkan spesifikasi, dan inilah yang memungkinkan Anda memakai ulang kode teruji alih-alih menulis kriptografi dengan tangan.

Artinya ke Depan

Bagi developer agent, otorisasi bukan lagi renungan yang ditempel di akhir. Jika Anda membangun atau memakai server MCP remote, alur OAuth adalah bagian dari kontrak inti, dan menganggapnya opsional adalah cara token bocor dan server disalahgunakan. Kabar baiknya, ekosistemnya mulai menyatu: klien seperti Claude sudah memandu pengguna melewati jabat tangan OAuth saat menambahkan connector remote.

• Bersiaplah mengimplementasikan atau mengintegrasikan alur authorization code plus PKCE secara penuh, bukan jalan pintas.
• Kunci revisi spesifikasi bertanggal yang Anda targetkan, karena syaratnya bergeser antar versi.
• Bersandarlah pada penyedia identitas dan pustaka framework agar Anda memvalidasi audience dan merotasi token dengan benar.

MCP OAuth sulit karena ia jujur mencerminkan betapa sulitnya akses terdelegasi yang aman begitu sebuah server meninggalkan laptop Anda dan menghadap internet. Frustrasinya nyata, tetapi hampir semuanya lenyap saat Anda memakai ulang penyedia identitas yang layak dan menjaga resource server dan authorization server sebagai peran yang berbeda. Benahi pemisahan itu, sisanya hanyalah pipa.