Uwierzytelnianie to najbardziej krytyczna warstwa bezpieczeństwa dla zdalnych serwerów MCP. Dowiedz się, dlaczego OAuth 2.1 z OIDC jest obowiązkowy, jak delegacja tokenów zapobiega atakowi pomylonego zastępcy i dlaczego przekazywanie tokenów jest jednym z najbardziej niebezpiecznych wzorców w integracjach AI.
Uwierzytelnianie to strażnik, który określa, czy potężne możliwości serwera MCP są dostępne dla uprawnionych użytkowników, czy dla atakujących. Jeśli zrobisz to źle, każda inna kontrola bezpieczeństwa staje się nieistotna — nieuwierzytelniony lub słabo uwierzytelniony serwer MCP z dostępem do poczty e-mail, plików i baz danych jest krytyczną podatnością, niezależnie od tego, jak dobrze zabezpieczyłeś wszystko inne.
Przewodnik projektu OWASP GenAI Security Project identyfikuje uwierzytelnianie i autoryzację jako jedną z ośmiu podstawowych domen bezpieczeństwa dla serwerów MCP, ze szczegółowymi wymaganiami, które wykraczają poza to, co większość programistów implementuje domyślnie. Ten post wyjaśnia, dlaczego te wymagania istnieją i jak je poprawnie wdrożyć.
Serwery MCP stają przed bardziej złożonym krajobrazem uwierzytelniania niż tradycyjne usługi, ponieważ pośredniczą między wieloma podmiotami:
Każda z tych relacji wymaga własnych kontroli uwierzytelniania i autoryzacji. Słabość w którymkolwiek ogniwie może zostać wykorzystana do ominięcia pozostałych.
Dla zdalnych serwerów MCP — tych dostępnych przez sieć, a nie przez lokalne STDIO lub gniazda Unix — przewodnik OWASP GenAI jest jednoznaczny: OAuth 2.1 z OIDC jest obowiązkowy, nie opcjonalny.
To wymaganie istnieje, ponieważ:
OAuth 2.1 zapewnia jawną kontrolę zakresu. Każdy token dostępu deklaruje dokładnie, które zasoby i działania autoryzuje. Serwer MCP może zweryfikować w czasie wywołania narzędzia, że przedstawiony token ma określony zakres potrzebny do tego działania — nie tylko, że użytkownik jest uwierzytelniony, ale że jest autoryzowany do tej konkretnej operacji.
OIDC zapewnia kryptograficzną tożsamość. OpenID Connect dodaje asercje tożsamości (token ID), które serwer MCP może zweryfikować bez komunikacji zwrotnej z dostawcą tożsamości. Serwer waliduje iss (wystawca), aud (odbiorcy), exp (wygaśnięcie) i podpis przy każdym żądaniu.
Tokeny OAuth 2.1 są z założenia krótkotrwałe. Nowoczesna specyfikacja OAuth (która konsoliduje i zastępuje najlepsze praktyki OAuth 2.0) kładzie nacisk na krótkotrwałe tokeny dostępu, które muszą być regularnie odświeżane. To ogranicza okno szkód, jeśli token zostanie skompromitowany.
Nie waliduj tokenów tylko przy ustanawianiu sesji. Waliduj przy każdym wywołaniu narzędzia:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Nigdy nie buforuj wyników walidacji między żądaniami. Token, który był ważny na początku sesji, może zostać cofnięty w trakcie sesji.
W środowiskach, gdzie klienci MCP zmieniają się często (np. różni asystenci AI łączący się z tym samym serwerem), statyczne klucze API lub wstępnie udostępnione sekrety są niewystarczające. Użyj dynamicznej rejestracji klienta z OAuth 2.1 lub OIDC, aby zweryfikować tożsamość klienta w czasie połączenia. Listy dozwolonych, zakodowane na stałe zasady połączeń lub wzajemny TLS (mTLS) są odpowiednie dla znanych statycznych relacji między określonymi klientami a serwerami.
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Pomylony zastępca to klasyczna podatność autoryzacji o szczególnie niebezpiecznym przejawie w architekturach MCP. Atak wykorzystuje niejednoznaczność tego, czyim autorytetem działa serwer MCP.
Rozważmy ten scenariusz:
Gdy Alicja prosi asystenta AI o “podsumowanie mojego folderu projektu”, serwer używa tokenu Alicji do dostępu do jej plików — poprawne zachowanie. Ale jeśli atakujący nakłoni serwer do wykonania żądania przy użyciu własnych poświadczeń usługi (być może przez atak zatruwania narzędzi lub pośrednią iniekcję promptu), podwyższone uprawnienia serwera są używane do dostępu do plików, do których Alicja nie jest autoryzowana.
Serwer jest “pomylonym zastępcą” — został nakłoniony do użycia swojego autorytetu w imieniu kogoś, kto nie ma tego autorytetu, działając jako pośrednik dla eskalacji uprawnień.
Wiele implementacji MCP przekazuje token klienta do podrzędnych API dla uproszczenia. Wydaje się to intuicyjne — token użytkownika reprezentuje uprawnienia użytkownika, więc używanie go do wszystkich wywołań podrzędnych utrzymuje poprawną kontrolę dostępu.
Problem: podrzędne API, które rozpoznają serwer MCP jako zaufanego pośrednika, mogą przyznawać żądania przy użyciu poziomu tożsamości serwera, a nie poziomu przekazanego tokenu użytkownika. A jeśli serwer MCP kiedykolwiek działa z własnej inicjatywy — poprzez podejmowanie decyzji AI, o które użytkownik nie prosił jawnie — może użyć własnych poświadczeń zamiast tokenu użytkownika.
Przekazywanie tokenów użytkowników również:
Zamiast przekazywać tokeny klientów, serwer MCP powinien uzyskać własne tokeny dla dostępu do usług podrzędnych przy użyciu przepływu On-Behalf-Of (OBO) OAuth:
Użytkownik uwierzytelnia się na kliencie MCP → klient otrzymuje token dostępu użytkownika
Klient MCP przedstawia token użytkownika serwerowi MCP
Serwer MCP wymienia token użytkownika na token serwera przez przepływ OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Serwer MCP używa własnego tokenu OBO do wywołań podrzędnych
Token OBO:
Przewodnik OWASP GenAI zawiera konkretne zalecenie: wystawiaj tokeny dostępu z czasem życia mierzonym w minutach, a nie godzinach. Dotyczy to zarówno tokenów, które serwer MCP akceptuje od klientów, jak i tokenów, które uzyskuje dla dostępu do usług podrzędnych.
Skradziony token dostępu jest ważny przez cały czas życia, niezależnie od tego, czy uprawniony użytkownik się wylogował, zmienił hasło czy cofnął swoją sesję. Token 24-godzinny skradziony na początku sesji daje atakującemu 24 godziny trwałego dostępu. Token 5-minutowy skradziony w połowie sesji daje maksymalnie 5 minut.
Krótkotrwałe tokeny wymuszają również regularne zdarzenia ponownego uwierzytelniania, które zapewniają możliwości do:
Każdy token powinien zawierać tylko zakresy potrzebne do konkretnej wykonywanej operacji. Nie wystawiaj tokenu z zakresem read:files write:files delete:files, gdy bieżące wywołanie narzędzia potrzebuje tylko read:files. To ogranicza szkody, jeśli token zostanie przechwycony lub model zostanie zmanipulowany do nieoczekiwanych wywołań narzędzi.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mapuj narzędzie na minimalne wymagane zakresy
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5-minutowy czas życia
)
Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.
Powszechnym błędem jest używanie identyfikatorów sesji jako pośredników autoryzacji: jeśli żądanie niesie ważny identyfikator sesji, serwer zakłada, że jest autoryzowane. To łączy zarządzanie stanem z weryfikacją tożsamości.
Prawidłowy model: identyfikatory sesji zarządzają stanem konwersacji. Autoryzacja jest weryfikowana niezależnie przy każdym żądaniu przez walidację roszczeń tokenu OAuth. Nawet żądanie niosące ważny identyfikator sesji musi przedstawić ważny, niewygasły, odpowiednio ograniczony token OAuth, zanim jakiekolwiek wywołanie narzędzia zostanie dozwolone.
To ma znaczenie, ponieważ identyfikatory sesji mogą zostać skradzione, odgadnięte lub odtworzone w sposób, w jaki tokeny OAuth — które niosą kryptograficzne gwarancje integralności — nie mogą.
Zamiast implementować kontrole autoryzacji rozproszone w poszczególnych procedurach obsługi narzędzi, przewodnik OWASP GenAI zaleca scentralizowaną bramę zasad, która:
Centralizacja zapewnia, że zasady są konsekwentnie stosowane we wszystkich narzędziach i agentach. Kontrola autoryzacji specyficzna dla narzędzia może zostać zapomniana lub ominięta podczas rozwoju; kontrola bramy nie może.
Dla zdalnych serwerów MCP minimalny poziom bezpieczeństwa uwierzytelniania to:
OAuth 2.1 jest wymagany dla zdalnych serwerów MCP, ponieważ zapewnia delegowaną autoryzację z jawną kontrolą zakresu, krótkotrwałe tokeny, weryfikację kryptograficzną i standaryzowane asercje tożsamości (poprzez OIDC). Prostsze metody, takie jak klucze API lub ciasteczka sesji, nie posiadają szczegółowości zakresu potrzebnej do wdrożenia dostępu z najmniejszymi uprawnieniami, nie zapewniają kryptograficznych gwarancji tożsamości i są trudne do szczegółowego cofnięcia, gdy sesja się kończy.
Pomylony zastępca to atak eskalacji uprawnień, w którym serwer MCP jest nakłaniany do użycia własnych (wyższych) uprawnień do wykonywania działań, do których użytkownik żądający nie jest autoryzowany. Występuje, gdy używane jest przekazywanie tokenów — serwer przekazuje token użytkownika do podrzędnych API, które mogą przyznać użytkownikowi dostęp, którego nie powinien mieć na podstawie zaufanego statusu serwera. Rozwiązaniem jest użycie przepływów tokenów On-Behalf-Of, gdzie tokeny są jawnie wystawiane dla określonego zakresu dostępu serwera MCP.
Przekazywanie tokenów oznacza, że serwer MCP przekazuje token uwierzytelniania klienta bezpośrednio do podrzędnych API, zamiast używać własnych poświadczeń wystawionych dla serwera. Jest to niebezpieczne, ponieważ: (1) przerywa ścieżki audytu — systemy podrzędne widzą token użytkownika, a nie serwer MCP, co uniemożliwia przypisanie działań do serwera; (2) omija własne zasady dostępu serwera MCP; (3) tworzy podatność pomylonego zastępcy, jeśli podrzędne API ufa tożsamości serwera MCP bardziej niż użytkownika; oraz (4) jeśli serwer MCP zostanie skompromitowany, atakujący uzyskuje dostęp do przekazywanych tokenów użytkowników dla wszystkich połączonych usług podrzędnych.
Przewodnik OWASP GenAI zaleca tokeny z czasem życia mierzonym w minutach, a nie godzinach czy dniach. Krótsze czasy życia tokenów ograniczają okno eksploatacji, jeśli token zostanie skradziony lub sesja zostanie przejęta. Każde wywołanie narzędzia powinno ponownie walidować podpis tokenu, odbiorców i wygaśnięcie — nie polegać na buforowanej walidacji od początku sesji.
Arshia jest Inżynierką Przepływów Pracy AI w FlowHunt. Z wykształceniem informatycznym i pasją do sztucznej inteligencji, specjalizuje się w tworzeniu wydajnych przepływów pracy, które integrują narzędzia AI z codziennymi zadaniami, zwiększając produktywność i kreatywność.
Nasz zespół bezpieczeństwa ocenia konfiguracje uwierzytelniania MCP, obsługę tokenów i przepływy autoryzacji zgodnie ze standardami OWASP GenAI. Zidentyfikuj luki zanim zrobią to atakujący.
Serwery MCP ujawniają unikalną powierzchnię ataku łączącą tradycyjne zagrożenia API z zagrożeniami specyficznymi dla AI. Poznaj 6 krytycznych podatności zidenty...
Wstrzykiwanie promptów to podstawowy wektor ataku na serwery MCP w środowisku produkcyjnym. Poznaj cztery kontrole zalecane przez OWASP: strukturalne wywołanie ...
Attestowalny Serwer MCP wprowadza zdalną atestację i przetwarzanie poufne do przepływów pracy FlowHunt, umożliwiając agentom AI i klientom weryfikację integraln...