Dogłębna recenzja specyfikacji autoryzacji MCP (wydanie z 2025-03-26)

MCP (Model Context Protocol) to otwarty standard, który umożliwia modelom AI interakcję z zewnętrznymi narzędziami i usługami. Jest powszechnie stosowany w branży. Ponieważ MCP wspiera metody transportu oparte na HTTP, Zdalny Serwer MCP będzie odgrywał coraz ważniejszą rolę w ekosystemie MCP.

W przeciwieństwie do Lokalnego Serwera MCP, który pozwala każdemu użytkownikowi na uruchomienie własnej instancji serwera, Zdalny Serwer MCP wymaga, aby wszyscy użytkownicy dzielili ten sam system serwera MCP. Stawia to kluczowy problem, który Specyfikacja Autoryzacji MCP (MCP Authorization Spec) ma rozwiązać: jak pozwolić Serwerowi MCP na dostęp do zasobów użytkownika w imieniu użytkownika.

Ten artykuł przeanalizuje dogłębnie Specyfikację Autoryzacji MCP. Pomoże ci zrozumieć zasady projektowania Specyfikacji Autoryzacji MCP oraz kierunki implementacji autoryzacji MCP. Ponieważ Specyfikacja ta cały czas się rozwija, podzielę się myślami opartymi na moim osobistym doświadczeniu w implementacji Autentykatora, w tym:

• Zalety i ograniczenia OAuth 2.1 jako struktury autoryzacyjnej
• Wyzwania związane z podwójnymi rolami Serwera MCP jako Serwera Autoryzacji i Serwera Zasobów
• Praktyczna złożoność wdrażania pełnego Serwera Autoryzacji
• Analiza odpowiednich scenariuszy dla delegowanej autoryzacji stron trzecich
• Praktyczne kompromisy Dynamicznej Rejestracji Klienta
• Znaczenie wyraźnego definiowania granic zasobów Serwera MCP

Przegląd Specyfikacji Autoryzacji MCP#

MCP Authorization Spec definiuje proces uwierzytelniania między Serwerem MCP (Zdalnym) a Klientem MCP.

Uważam, że oparcie tej Specyfikacji na OAuth 2.1 jest bardzo rozsądnym wyborem. OAuth jako rama protokołów autoryzacyjnych rozwiązuje problem, jak pozwolić użytkownikom na autoryzację aplikacji stron trzecich do uzyskania dostępu do zasobów użytkownika w ich imieniu. Jeśli nie jesteś zaznajomiony z OAuth, możesz sprawdzić AuthWiki-OAuth dla uzyskania większej ilości informacji.

W scenariuszu Klient MCP i Serwer MCP chodzi o " użytkowników autoryzujących Klienta MCP do uzyskania dostępu do zasobów użytkownika na Serwerze MCP". "Zasoby użytkownika na Serwerze MCP" obecnie głównie odnoszą się do narzędzi oferowanych przez Serwer MCP lub zasobów dostarczanych przez usługi backendowe Serwera MCP.

Aby wdrożyć proces uwierzytelniania OAuth 2.1, protokół wymaga, aby Serwer MCP dostarczał następujące interfejsy, aby współpracować z Klientem MCP w celu ukończenia procesu uwierzytelniania OAuth 2.1:

• /.well-known/oauth-authorization-server: Metadane serwera OAuth
• /authorize: Punkt końcowy autoryzacji, używany do zapytań o autoryzację
• /token: Punkt końcowy oznakowania, używany do wymiany tokenów i odświeżania
• /register: Punkt końcowy rejestracji klienta, używany do dynamicznej rejestracji klienta

Proces uwierzytelniania jest następujący:

Specyfikacja określa również, jak Serwer MCP wspiera delegowaną autoryzację przez serwery autoryzacyjne stron trzecich.

Przykładowy przepływ w Specyfikacji jest następujący (zawartość z Specyfikacji):

W tym scenariuszu, choć Serwer MCP deleguje autoryzację do serwera autoryzacyjnego strony trzeciej, Serwer MCP nadal działa jako serwer autoryzacyjny dla Klienta MCP. Dzieje się tak, ponieważ Serwer MCP musi wydać własny token dostępu Klientowi MCP.

Z mojego punktu widzenia, scenariusz ten wydaje się bardziej odpowiedni do sytuacji, w których Serwer MCP pełni rolę pośrednika między Klientem MCP (użytkownikiem) a zasobami stron trzecich (takimi jak repozytoria Github), zamiast Serwer MCP pełniącego rolę pośrednika w dostępie Klienta MCP (użytkownika) do własnych zasobów Serwera MCP.

Podsumowując, zgodnie z protokołem, Serwer MCP pełni jednocześnie rolę Serwera Autoryzacyjnego i Serwera Zasobów w OAuth.

Następnie omówmy odpowiedzialności Serwera MCP jako Serwera Autoryzacyjnego i Serwera Zasobów.

Serwer MCP jako usługa autoryzacyjna#

Kiedy Serwer MCP działa jako Serwer Autoryzacyjny, oznacza to, że użytkownik końcowy Klienta MCP ma własną tożsamość na Serwerze MCP. Serwer MCP odpowiada za uwierzytelnienie tego użytkownika końcowego i wydanie mu tokenu dostępu do zasobów Serwera MCP.

Powyżej wspomniane interfejsy związane z autoryzacją wymagane przez Specyfikację Autoryzacji MCP oznaczają, że Serwer MCP musi zapewnić implementację funkcji Serwera Autoryzacyjnego.

Jednak wdrożenie funkcjonalności Serwera Autoryzacyjnego na Serwerze MCP stanowi znaczące wyzwanie dla deweloperów. Z jednej strony, większość deweloperów może być nie zaznajomiona z koncepcjami związanymi z OAuth. Z drugiej strony, istnieje wiele szczegółów do rozważenia podczas implementacji Serwera Autoryzacyjnego. Jeśli deweloper nie pochodzi z pokrewnej dziedziny, mogą w trakcie implementacji wprowadzić problemy, takie jak kwestie bezpieczeństwa.

Jednakże sam protokół nie ogranicza Serwera MCP do samodzielnego wdrożenia funkcjonalności Serwera Autoryzacyjnego. Deweloperzy mogą całkowicie przekierować lub pośredniczyć tymi interfejsami związanymi z autoryzacją do innych serwerów autoryzacyjnych. Nie różni się to dla Klienta MCP niż samodzielne wdrożenie funkcjonalności Serwera Autoryzacyjnego przez Serwer MCP.

Możesz się zastanawiać, czy takie podejście powinno używać wspomnianej powyżej metody delegowanej autoryzacji strony trzeciej?

Z mojego punktu widzenia, to głównie zależy od tego, czy użytkownicy usługi autoryzacyjnej strony trzeciej, na której polegasz, są tacy sami jak końcowi użytkownicy Serwera MCP. Oznacza to, że token dostępu wydany przez usługę autoryzacyjną strony trzeciej będzie bezpośrednio konsumowany przez twój Serwer MCP.

• Jeśli tak, to możesz całkowicie przekierować interfejsy związane z autoryzacją w swoim Serwerze MCP do usług autoryzacyjnych stron trzecich.

• Jeśli nie, powinieneś użyć podejścia delegowanej autoryzacji stron trzecich określonego w Specyfikacji. Musisz utrzymywać mapowanie relacji między tokenami dostępu wydanymi przez sam Serwer MCP a tokenami dostępu wydanymi przez usługi autoryzacyjne stron trzecich w Serwerze MCP.

Uważam, że podejście delegowanej autoryzacji stron trzecich określone w protokole jest nieco niejasne w praktycznych scenariuszach aplikacyjnych. Protokół wydaje się pozwalać stronom trzecim na pomoc Serwerowi MCP w ukończeniu procesu autoryzacji, ale nadal wymaga, aby Serwer MCP wydał własny token dostępu. Oznacza to, że Serwer MCP nadal ponosi odpowiedzialność za wydawanie tokenów dostępu jako Serwer Autoryzacyjny, co nie jest bardziej wygodne dla deweloperów. Uważam, że prawdopodobnie autorzy protokołu rozważyli, że bezpośrednie zwracanie tokenów dostępu stron trzecich do Klienta MCP może wywołać pewne problemy z bezpieczeństwem (takie jak wyciek/nadużycie, itp.).

Z mojego doświadczenia, najbardziej odpowiednim scenariuszem dla podejścia delegowanej autoryzacji stron trzecich określonego w protokole powinien być scenariusz "użytkownicy autoryzują Serwer MCP do uzyskania dostępu do zasobów stron trzecich". Na przykład, Serwer MCP musi uzyskać dostęp do repozytorium Github użytkownika i wdrożyć kod repozytorium na platformie wdrożenia kodu. W takim przypadku użytkownik musi autoryzować Serwer MCP do uzyskania dostępu do repozytorium Github i do uzyskania dostępu do platformy wdrożenia kodu.

W tym scenariuszu, Serwer MCP jest Serwerem Autoryzacyjnym dla Klienta MCP, ponieważ użytkownicy końcowi mają własną tożsamość w Serwerze MCP. Serwer MCP jest Klientem stron trzecich dla zasobów stron trzecich (w tym przypadku Github). Musi uzyskać autoryzację użytkownika, aby uzyskać dostęp do zasobów użytkownika na Github. Pomiędzy Klientem MCP a Serwerem MCP oraz pomiędzy Serwerem MCP a zasobami stron trzecich tożsamości użytkowników są odseparowane. To sprawia, że utrzymanie mapowania relacji między tokenami dostępu wydanymi przez sam Serwer MCP a tokenami dostępu wydanymi przez usługi autoryzacyjne stron trzecich w Serwerze MCP jest uzasadnione.

Tak więc podejście delegowanej autoryzacji stron trzecich w protokole powinno rozwiązać problem "jak użytkownicy autoryzują Serwer MCP do uzyskania dostępu do zasobów użytkowników na Serwerach Zasobów stron trzecich".

Serwer MCP jako Serwer Zasobów#

Kiedy Serwer MCP działa jako Serwer Zasobów, Serwer MCP musi zweryfikować, czy żądanie Klienta MCP posiada ważny token dostępu. Serwer MCP zdecyduje, czy pozwolić Klientowi MCP na uzyskanie dostępu do konkretnych zasobów na podstawie zakresu tokenu dostępu.

Z definicji MCP, Zasób oferowany przez Serwer MCP powinien być narzędziami do użycia przez Klienta MCP. W tym scenariuszu, Serwer MCP musi tylko zdecydować, czy zapewnić użytkownikom dostęp do określonych narzędzi.

Ale w rzeczywistych scenariuszach, te narzędzia oferowane przez Serwer MCP muszą również współdziałać z Serwerem Zasobów dostawcy usługi Serwera MCP. W tym czasie token dostępu uzyskany przez Serwer MCP z żądania klienta musi być użyty do uzyskania dostępu do własnego Serwera Zasobów. W większości przypadków, Serwer MCP i Serwer Zasobów stojący za narzędziami są tego samego dewelopera. Serwer MCP to tylko interfejs oferowany przez własne zasoby backendowe do użycia dla Klienta MCP. W tym czasie, Serwer MCP może dzielić ten sam token dostępu wydany przez jeden Serwer Autoryzacyjny z zasobami backendowymi.

W takim przypadku, zamiast mówić, że Serwer MCP jest Serwerem Zasobów, oferując narzędzia i Zasoby własnej usługi, lepiej powiedzieć, że istniejący Serwer Zasobów staje się Serwerem MCP, oferując narzędzia do wywołania przez Klienta MCP.

Ujęcie zasobów dostarczanych przez własny Serwer Zasobów w Zasoby oferowane przez Serwer MCP wynika bardziej z rozważenia rzeczywistych scenariuszy. Ale osobiście nadal wolę, aby Zasoby oferowane przez Serwer MCP to tylko narzędzia używane przez Klienta MCP, a zasoby od których narzędzia zależą powinny być zasobami uzyskiwanymi przez Serwer MCP od innych Serwerów Zasobów (w tym pierwszych i trzecich stron). Tym sposobem, wszystkie rzeczywiste scenariusze mogą zostać pokryte.

Jak działa autoryzacja MCP#

Po zrozumieniu odpowiedzialności Serwera MCP jako Serwera Autoryzacyjnego i Serwera Zasobów, możemy wiedzieć, jak dokładnie działa Autoryzacja MCP:

Dynamiczna Rejestracja Klienta#

Specyfikacja również definiuje, jak Serwer Autoryzacyjny identyfikuje Klientów. OAuth 2.1 dostarcza Protokołu Dynamicznej Rejestracji Klienta, co pozwala Klientowi MCP automatycznie uzyskać identyfikator klienta OAuth bez interwencji użytkownika.

Zgodnie ze Specyfikacją, Serwer MCP powinien obsługiwać Protokoł Dynamicznej Rejestracji Klienta OAuth 2.0. Tym sposobem, Klient MCP może automatycznie rejestrować się w nowych serwerach, aby uzyskać identyfikator klienta OAuth. Podejście to jest zalecane w scenariuszach MCP głównie dlatego, że:

• Klient MCP nie może znać wszystkich możliwych serwerów z góry
• Ręczna rejestracja sprawiałaby kłopot użytkownikom
• Umożliwia bezszwładne połączenie z nowymi serwerami
• Serwery mogą wdrażać własne polityki rejestracyjne

Jednak z praktycznego punktu widzenia, mam przemyślenia dotyczące stosowania Dynamicznej Rejestracji Klienta w scenariuszach MCP:

• W praktycznych praktykach usług OAuth, Klient zazwyczaj odpowiada jeden do jednego za konkretną aplikację biznesową. Dynamiczne tworzenie Klienta może nie sprzyjać efektywnemu zarządzaniu powiązanymi zasobami (użytkownicy, aplikacje, itd.) w usługach OAuth. Dostawcy usług OAuth zwykle chcą mieć jasno określoną kontrolę nad połączonymi Klientami, zamiast pozwalać na rejestrację dowolnego klienta jako Klient.
• Wiele usług OAuth nie zaleca lub nie pozwala użytkownikom na dynamiczne tworzenie Klientów, ponieważ może to prowadzić do nadużycia usług. Większość dojrzałych dostawców usług OAuth (takich jak GitHub, Google, itd.) wymaga od deweloperów ręcznej rejestracji Klientów poprzez ich konsolę deweloperską, a także może wymagać dostarczenia szczegółowych informacji na temat aplikacji, adresu URL callback itd.
• Ręczna rejestracja Klienta OAuth jest właściwie jednorazową pracą podczas rozwoju, nie jest to coś, co każdy użytkownik końcowy musi zrobić. Nie będzie to stanowiło dużego obciążenia dla deweloperów.
• Dla Klienta Publicznego (takich jak aplikacje natywne, jednostronicowe aplikacje, itd.), mamy bardziej bezpieczne sposoby na wdrożenie przepływu OAuth bez dynamicznej rejestracji. Identyfikator klienta połączony z PKCE (Proof Key for Code Exchange) może zapewnić wystarczająco bezpieczny przepływ OAuth dla Klienta Publicznego bez dynamicznego tworzenia Klienta.
• Chociaż protokół wskazuje, że użycie Dynamicznej Rejestracji Klienta może uniknąć konieczności wcześniejszej znajomości identyfikatora klienta przez klientów, w rzeczywistości Klient MCP zawsze musi znać adres Zdalnego Serwera MCP z wyprzedzeniem. Jeśli tak, określenie identyfikatora klienta podczas przekazywania adresu Zdalnego Serwera MCP nie przyniesie wiele dodatkowego kłopotu. Lub, możemy również stworzyć konwencję dla Klienta MCP, aby poprosić Serwer MCP o identyfikator klienta, co nie jest trudnym zadaniem.

Chociaż Dynamiczna Rejestracja Klienta teoretycznie zapewnia elastyczność dla ekosystemu MCP, w praktycznym wdrażaniu możemy musieć rozważyć, czy naprawdę potrzebujemy tego mechanizmu dynamicznej rejestracji. Dla większości dostawców usług, ręczne tworzenie i zarządzanie Klientami OAuth może być bardziej kontrolowanym i bezpiecznym sposobem.

Podsumowanie#

Ten artykuł dogłębnie analizuje filozofię projektowania i wyzwania implementacyjne Specyfikacji Autoryzacji MCP. Jako framework autoryzacyjny oparty na OAuth 2.1, specyfikacja ta ma na celu rozwiązanie kluczowego problemu, jakim jest dostęp Zdalnego Serwera MCP do zasobów użytkownika w imieniu użytkowników.

Poprzez szczegółowe omówienie podwójnych ról Serwera MCP jako Serwera Autoryzacyjnego i Serwera Zasobów, a także zalet i wad mechanizmów takich jak Dynamiczna Rejestracja Klienta i delegacja autoryzacji stron trzecich, ten artykuł dostarcza myśli i sugestii z osobistego doświadczenia w implementacji Autentykatora.

Warto zauważyć, że specyfikacja autoryzacji MCP ciągle się rozwija. Jako członek zespołu Logto będziemy kontynuować naszą uwagę na najnowszych rozwinięciach tej specyfikacji i ciągłe optymalizowanie naszych rozwiązań implementacyjnych w praktyce, aby przyczynić się do bezpiecznej interakcji między modelami AI a zewnętrznymi usługami.