Połączenie klienta z adresem URL serwera nie daje mu dostępu do chronionych danych konta. OAuth pozwala klientowi żądać delegowanego dostępu przez serwer autoryzacji, czyli usługę wydającą token.
Specyfikacja autoryzacji MCP definiuje ten przepływ dla transportów HTTP. Autoryzacja jest opcjonalna dla implementacji MCP. Lokalne serwery stdio korzystają z odrębnego mechanizmu uwierzytelniania.
Jak klient znajduje miejsce logowania?
Klient odczytuje metadane chronionego zasobu serwera MCP, aby odkryć jego serwer autoryzacji.
Zgodnie z regułami odkrywania serwer może podać adres URL metadanych w nagłówku WWW-Authenticate odpowiedzi 401. Klienty obsługują również odkrywanie przez dobrze znane ścieżki metadanych.
Pole authorization_servers w metadanych wskazuje dostępne serwery autoryzacji. Klient pobiera metadane wybranego serwera, aby znaleźć jego punkty końcowe i obsługiwane możliwości.
Jak klient się identyfikuje?
Klient uzyskuje identyfikator klienta (client ID) przez mechanizm rejestracji obsługiwany przez serwer autoryzacji.
Reguły rejestracji MCP preferują istniejące, wcześniej zarejestrowane dane klienta, jeśli są dostępne. W przeciwnym razie klienty mogą używać dokumentów Client ID Metadata Document, gdy serwer ogłasza ich obsługę.
Client ID Metadata Document to dokument JSON pod adresem URL HTTPS opisujący klienta. Ten adres URL pełni rolę jego identyfikatora klienta.
Te reguły uznają dynamiczną rejestrację klienta za przestarzałą. Mechanizm ten pozwala klientowi żądać identyfikatora przez punkt końcowy rejestracji. Specyfikacja zachowuje go dla kompatybilności z serwerami autoryzacji, które nie obsługują dokumentów metadanych.
Jak klient uzyskuje token?
Klient wymienia kod autoryzacji na token dostępu po zatwierdzeniu przyznania przez serwer autoryzacji.
Reguły ochrony kodu autoryzacji wymagają PKCE, które wiąże wymianę z klientem, który ją zainicjował. Klient tworzy tajny weryfikator i wysyła wyprowadzone wyzwanie wraz z żądaniem autoryzacji. Podaje weryfikator przy realizacji kodu, co pomaga zapobiec użyciu przechwyconego kodu przez innego wywołującego.
Co kontrolują zakresy i zasób docelowy?
Zakresy opisują żądane uprawnienia. Zasób docelowy wskazuje serwer, dla którego klient żąda tokenu.
Reguły wyboru zakresu nakazują klientom używanie wartości scope z wyzwania, jeśli jest podana. Klient powinien żądać dostępu potrzebnego do danej operacji.
Klient dołącza parametr resource do żądań autoryzacji i tokenu. Wysyła uzyskany token w nagłówku Authorization w chronionych żądaniach HTTP. Serwer odbierający sprawdza, czy token został wystawiony dla niego.
Uprawnienie do wywołania narzędzia nie oznacza, że dane wywołanie odpowiada zadaniu użytkownika. Host nadal decyduje, czy kontynuować proponowaną akcję.
Jak autoryzować klienta do korzystania z Bird?
Dodaj hostowany adres URL MCP usługi Bird do kompatybilnego klienta i dokończ logowanie przez przeglądarkę.
Udokumentowany handshake Bird używa dynamicznej rejestracji klienta. Opisuje to przepływ połączenia Bird oddzielnie od preferowanego przez specyfikację mechanizmu dokumentów metadanych.
Na ekranie zgody wybierz uprawnienia obszaru roboczego lub organizacji do delegowania. Przyznanie jest ograniczone tym, czego żąda klient, co zatwierdzisz i czym dysponujesz.
Wyświetlana nazwa klienta jest deklarowana przez niego samego, więc upewnij się, że odpowiada klientowi, którego uruchomiłeś. Możesz cofnąć przyznanie w sekcji Connected apps w swoim profilu.
Narzędzie może pozostać na liście, nawet gdy Twoje przyznanie nie obejmuje uprawnienia do jego wywołania. Pomyślne wywołanie whoami potwierdza tożsamość zalogowanego użytkownika. Żądana operacja nadal wymaga własnych uprawnień.
W przypadku lokalnego procesu bird mcp serwer ponownie wykorzystuje zapisane dane logowania CLI. Przewodnik konfiguracji MCP opisuje tę odrębną ścieżkę.