Perbaikan Konfigurasi OpenID untuk Konektor MCP
Saya menghabiskan terlalu banyak waktu minggu ini untuk memperbaiki konektor MCP jarak jauh.
Konektor tersebut terus gagal menemukan server OAuth saya. Servernya berjalan dengan baik. Masalahnya adalah satu rute yang hilang dan sebuah redirect.
Saat Anda menggunakan OAuth dengan MCP, Anda mengharapkan dokumen penemuan (discovery documents) berfungsi. Sebagian besar alat mencari dua jalur ini:
- /.well-known/oauth-authorization-server
- /.well-known/oauth-protected-resource
Ini memberi tahu klien di mana menemukan endpoint otorisasi dan token.
Masalahnya adalah banyak klien tidak mencari jalur spesifik tersebut. Sebaliknya, mereka mencari /.well-known/openid-configuration.
Ini adalah jalur OpenID Connect. Ini adalah spesifikasi yang berbeda, tetapi berada di tempat yang sama. Paket saya tidak mendaftarkan jalur ini karena mengikuti spesifikasi OAuth, bukan spesifikasi OIDC.
Klien mengetuk pintu yang tidak ada. Ia mendapatkan error 404 dan berhenti.
Saya punya dua pilihan:
Menggunakan redirect reverse-proxy di Nginx. Ini adalah perbaikan yang malas. Ini memindahkan logika Anda keluar dari kode dan ke dalam infrastruktur Anda. Ini sulit diuji dan mudah rusak saat deployment.
Memperbaikinya di dalam aplikasi. Ini adalah cara yang lebih baik.
Saya memilih untuk membuat aplikasi menjawab permintaan tersebut. Saya membuat alias yang mengalihkan jalur OpenID ke jalur otorisasi OAuth.
Saya menggunakan 308 Permanent Redirect.
Redirect 302 dapat mengubah permintaan POST menjadi permintaan GET. Redirect 308 bersifat ketat. Ia memberi tahu klien untuk pergi ke URL baru dan tetap menggunakan metode serta body yang sama. Ini adalah cara yang benar untuk menangani perpindahan permanen.
Saya juga menempatkan ini di balik flag konfigurasi. Ini memungkinkan pengguna untuk mematikannya jika mereka menjalankan penemuan OIDC mereka sendiri.
Dengan melakukan ini di dalam kode, saya dapat menulis pengujian:
- Satu pengujian memeriksa apakah redirect terjadi dengan benar.
- Satu pengujian mengikuti redirect untuk memastikan metadata valid.
Ini memastikan bahwa jika struktur metadata berubah, pengujian saya akan langsung gagal. Saya menemukan error di pipeline saya, alih-alih menemukannya saat pengguna tidak dapat terhubung.
Spesifikasi sering kali berbeda dalam praktiknya. Bahkan ketika dua standar memiliki tujuan yang serupa, klien akan memilih jalur yang berbeda. Sebagai pengembang server, Anda harus menjawab kedua pintu tersebut.
Arahkan mereka ke ruangan yang sama, gunakan kode redirect yang tepat, dan dukung dengan pengujian.