Menghubungkan klien ke URL server tidak memberikan akses ke data akun yang dilindungi. OAuth memungkinkan klien meminta akses terdelegasi melalui authorization server, layanan yang menerbitkan token.
Spesifikasi otorisasi MCP mendefinisikan alur ini untuk transpor HTTP. Otorisasi bersifat opsional untuk implementasi MCP. Server stdio lokal menggunakan pengaturan kredensial terpisah.
Bagaimana klien menemukan tempat untuk masuk?
Klien membaca metadata protected-resource dari server MCP untuk menemukan authorization server-nya.
Berdasarkan aturan penemuan, server dapat menyediakan URL metadata tersebut dalam header WWW-Authenticate pada respons 401. Klien juga mendukung penemuan melalui jalur metadata well-known.
Field authorization_servers dalam metadata mengidentifikasi authorization server yang tersedia. Klien mengambil metadata server yang dipilih untuk menemukan endpoint dan kapabilitas yang didukung.
Bagaimana klien mengidentifikasi dirinya?
Klien memperoleh client ID melalui mekanisme registrasi yang didukung oleh authorization server.
Aturan registrasi MCP mengutamakan informasi klien yang sudah terdaftar sebelumnya jika tersedia. Jika tidak, klien dapat menggunakan Client ID Metadata Document saat server mengiklankan dukungannya.
Client ID Metadata Document adalah dokumen JSON di URL HTTPS yang mendeskripsikan klien. URL tersebut berfungsi sebagai client ID-nya.
Aturan tersebut menandai dynamic client registration sebagai usang. Mekanisme ini memungkinkan klien meminta ID melalui registration endpoint. Spesifikasi tetap mempertahankannya untuk kompatibilitas dengan authorization server yang belum mendukung metadata-document.
Bagaimana klien memperoleh token?
Klien menukarkan authorization code dengan access token setelah authorization server menyetujui pemberian akses.
Aturan perlindungan authorization-code mewajibkan PKCE, yang mengikat pertukaran ke klien yang memulainya. Klien membuat secret verifier dan mengirimkan challenge turunan bersama permintaan otorisasinya. Klien menyediakan verifier tersebut saat menukarkan code, sehingga membantu mencegah code yang disadap digunakan oleh pihak lain.
Apa yang dikendalikan oleh scope dan target resource?
Scope mendeskripsikan izin yang diminta. Target resource mengidentifikasi server yang menjadi tujuan klien meminta token.
Aturan pemilihan scope mengarahkan klien untuk menggunakan nilai scope dari challenge jika disediakan. Klien sebaiknya meminta akses yang dibutuhkan operasinya.
Klien menyertakan parameter resource dalam permintaan otorisasi dan token. Klien mengirimkan token yang dihasilkan dalam header Authorization pada permintaan HTTP yang dilindungi. Server penerima memeriksa bahwa token tersebut diterbitkan untuknya.
Izin untuk memanggil suatu tool tidak menjamin bahwa pemanggilan tertentu sesuai dengan tugas pengguna. Host tetap memutuskan apakah akan melanjutkan tindakan yang diusulkan.
Bagaimana cara mengotorisasi klien untuk menggunakan Bird?
Anda menambahkan URL MCP yang di-host Bird ke klien yang kompatibel dan menyelesaikan proses masuk browser-nya.
Handshake terdokumentasi Bird menggunakan dynamic client registration. Itu menjelaskan alur koneksi Bird secara terpisah dari mekanisme metadata-document yang direkomendasikan spesifikasi.
Di layar persetujuan, pilih izin workspace atau organisasi yang akan didelegasikan. Pemberian akses dibatasi oleh apa yang diminta klien, apa yang Anda setujui, dan apa yang Anda miliki.
Nama yang ditampilkan klien bersifat self-asserted, jadi pastikan nama tersebut sesuai dengan klien yang Anda jalankan. Anda dapat mencabut aksesnya dari Connected apps di profil Anda.
Suatu tool dapat tetap tercantum meskipun pemberian akses Anda tidak memiliki izin untuk memanggilnya. Panggilan whoami yang berhasil mengonfirmasi identitas yang masuk. Operasi yang diminta tetap memerlukan izinnya sendiri.
Untuk proses bird mcp lokal, server menggunakan kembali login tersimpan milik CLI. Panduan penyiapan MCP menjelaskan jalur terpisah tersebut.