Artykuł · MCP w firmie

Specyfikacja MCP 2026-07-28: autoryzacja nadal jest opcjonalna

Rewizja specyfikacji MCP 2026-07-28 zaostrza OAuth (walidacja iss, wycofanie DCR, wiązanie poświadczeń z wydawcą), ale autoryzacja pozostaje opcjonalna. Wymóg musi ustalić sama firma.

Dla: Architekci bezpieczeństwa, twórcy serwerów MCP, zespoły IAM · Stan na 02.11.2026 · Autor: Karol Krawczyk

Czy autoryzacja w MCP jest obowiązkowa?

Autoryzacja w MCP jest opcjonalna, bo rozdział o autoryzacji w specyfikacji 2026-07-28, w części o wymaganiach protokołu, mówi: Authorization is OPTIONAL for MCP implementations. Dalej następują warunki obowiązujące tylko wtedy, gdy implementacja autoryzację wspiera. Przy transporcie HTTP powinna (SHOULD) trzymać się tej specyfikacji. Przy stdio nie powinna (SHOULD NOT) i ma brać poświadczenia ze środowiska. Inne transporty muszą stosować dobre praktyki właściwe dla swojego protokołu.

Skutek jest taki, że serwer HTTP bez jakiejkolwiek kontroli dostępu może być w pełni zgodny ze specyfikacją. Rozdział o Streamable HTTP dorzuca jedynie zalecenie, by serwery wdrażały uwierzytelnianie wszystkich połączeń. Twarde wymagania, takie jak RFC 9728, PKCE czy walidacja odbiorcy tokenu, wchodzą do gry dopiero po decyzji, że autoryzacja jest. Deklaracja zgodny z MCP na stronie produktu nie odpowiada więc na pytanie, czy ktokolwiek sprawdza, kto łączy się z serwerem.

Dlaczego autoryzacja w MCP została opcjonalna?

Specyfikacja MCP ani ogłoszenie rewizji 2026-07-28 nie uzasadniają, dlaczego autoryzacja została opcjonalna, więc poniższe to interpretacja tego tekstu, której dokumentacja nie potwierdza. Oficjalny poradnik opisuje autoryzację jako silnie zalecaną, gdy serwer obsługuje dane użytkownika, potrzebny jest audyt albo środowisko korporacyjne, a dla stdio wskazuje poświadczenia ze środowiska. Da się z tego odczytać logikę: protokół obejmuje też serwer publiczny bez danych prywatnych i lokalny proces, gdzie OAuth w przeglądarce jest bez sensu. Obowiązkowy mechanizm zamknąłby te przypadki albo wymusił kolejne wyjątki.

Specyfikacja stwierdza też w sekcji o bezpieczeństwie, że MCP nie może wymuszać tych zasad na poziomie protokołu. Produkty mają podobną furtkę: dokumentacja gatewaya AWS wśród typów autoryzacji przychodzącej wymienia brak autoryzacji do testów. Decyzja należy do firmy. Propozycja tego tekstu to zapisana zasada: każdy serwer HTTP poza środowiskiem deweloperskim ma autoryzację opartą na tej specyfikacji albo pisemny wyjątek.

Zmiany rewizji MCP 2026-07-28 w OAuth

Zmiany OAuth w rewizji MCP 2026-07-28 dotyczą głównie klientów i serwerów autoryzacji. Wszystkie cztery pozycje poniżej wynikają z changelogu i aktualnego tekstu rozdziału.

Walidacja iss (RFC 9207, SEP-2468). Klient zapisuje oczekiwanego wydawcę przed przekierowaniem i porównuje go z parametrem iss w odpowiedzi, zanim wymieni kod na token. Serwer autoryzacji powinien (SHOULD) ten parametr wysyłać. Specyfikacja zapowiada podniesienie tego do MUST w przyszłej rewizji.
Wycofanie Dynamic Client Registration na rzecz Client ID Metadata Documents, gdzie identyfikatorem klienta jest adres HTTPS z dokumentem metadanych. DCR działa nadal, a rejestr wycofań podaje najwcześniejsze usunięcie w pierwszej rewizji z 2027-07-28 lub późniejszej.
application_type przy rejestracji dynamicznej (SEP-837), bez czego serwery OIDC mogą odrzucać przekierowania na localhost z aplikacji desktopowych i CLI.
Wiązanie poświadczeń z wydawcą (SEP-2352). Klient przechowuje je według identyfikatora serwera autoryzacji, nie używa ich u innego wydawcy, a po zmianie wydawcy rejestruje się ponownie.

Czego walidacja iss w MCP nie załatwia

Ogłoszenie rewizji 2026-07-28 mówi, że walidacja iss zamyka lukę mix-up, czyli atak, w którym złośliwy serwer autoryzacji wyłudza kod wydany przez uczciwy. Dokument z dobrymi praktykami jest ostrożniejszy: ochrona zależy od tego, czy uczciwy serwer wysyła iss, a wobec serwera, który tego nie robi, nie działa. Tabela walidacji to potwierdza: gdy metadane nie deklarują wsparcia i odpowiedź nie zawiera iss, klient idzie dalej. PKCE i resource indicators tego ataku nie powstrzymają, co dokument również zaznacza. W firmie trzeba więc sprawdzić konfigurację własnego dostawcy tożsamości, bo sama aktualizacja klienta nie wystarczy.

Podobna uwaga dotyczy CIMD. Mechanizm opiera się na szkicu IETF w wersji 00 i nie rozwiązuje podszywania się pod aplikację przez przekierowanie na localhost. Serwer autoryzacji powinien wtedy pokazać dodatkowe ostrzeżenie i musi wyraźnie wyświetlić nazwę hosta z adresu przekierowania. Pobieranie adresów podanych przez klienta otwiera po stronie serwera autoryzacji ryzyko SSRF. Dokument z dobrymi praktykami wymienia dla serwerów chronionych allowlistę zaufanych domen, więc ustaw ją w firmie.

Skutki bezstanowości MCP dla kontroli dostępu

Bezstanowość MCP zmienia też wymagania dotyczące autoryzacji. Protokół nie ma już sesji, więc nie ma identyfikatora, który serwer mógłby pomylić z dowodem tożsamości. Wymagania przeniosły się na uchwyty stanu: serwer, który potrzebuje stanu, wydaje identyfikator przekazywany jako zwykły argument narzędzia. Dobre praktyki nakazują, by sam fakt posiadania uchwytu nie był uwierzytelnieniem, i zalecają wiązanie go po stronie serwera z użytkownikiem z tokenu. Uchwyt przechodzi przy tym przez model, więc nie umieszczaj w nim niczego, czego model nie powinien zobaczyć.

Lista narzędzi nie może już zależeć od połączenia, ale może zależeć od autoryzacji żądania. Serwer ma prawo pokazać tylko to, na co pozwalają zakresy tokenu, co ułatwia ograniczanie agenta bez osobnych wdrożeń dla każdej grupy.

Przy okazji przeglądu sprawdź zakresy. Gdy odpowiedź 401 nie zawiera parametru scope, klient powinien (SHOULD) poprosić o wszystko z scopes_supported. Serwer, który publikuje tam pełny katalog, dostaje więc tokeny o maksymalnych uprawnieniach od samego początku, a dokument o dobrych praktykach wymienia to jako częsty błąd. Właściwy model to minimalny zestaw na start i podwyższanie przez odpowiedź 403 z insufficient_scope. Skradziony szeroki token pozwala od razu wywołać narzędzia wysokiego ryzyka, bez dodatkowego pytania o zgodę.

Enterprise-Managed Authorization poza rdzeniem specyfikacji MCP

Enterprise-Managed Authorization (wcześniej opisywane jako Cross App Access, SEP-990) to rozszerzenie MCP spoza rdzenia specyfikacji: pracownik loguje się do klienta przez firmowego dostawcę tożsamości, a ten według polityki administratora wystawia grant, który klient wymienia na token do serwera MCP, bez ekranu zgody przy każdym serwerze. Blog MCP wymienił je wśród pierwszych rozszerzeń autoryzacji przy okazji rewizji 2025-11-25, jednak changelog tej rewizji o nim nie wspomina. Status stabilny ogłoszono 18 czerwca 2026.

Wdrożenie ma ograniczenia. Pierwszym wspieranym dostawcą tożsamości jest Okta, po stronie serwerów ogłoszenie wymienia między innymi Asanę, Atlassiana, Figmę, Linear i Supabase, a po stronie klientów Claude, Claude Code, Cowork i Visual Studio Code. Grant opiera się na dokumencie IETF, który na 2 listopada 2026 nadal jest roboczym Internet-Draftem (wersja 06). Rozszerzenia są opcjonalne, więc obie strony muszą je zadeklarować, a na serwerze wewnętrznym wsparcie musi dodać zespół, który go utrzymuje. Na firmy z Entra ID lub innym dostawcą tożsamości ogłoszenie nie odpowiada, więc trzeba to sprawdzić bezpośrednio u producenta.

Co zrobić w firmie

Zapisz zasadę: serwer HTTP poza dev ma autoryzację według specyfikacji albo pisemny wyjątek
Sprawdź, czy dostawca tożsamości wysyła iss i deklaruje to w metadanych
Zinwentaryzuj klientów opartych na DCR i zaplanuj przejście na CIMD lub rejestrację wstępną
Dla CIMD ustaw allowlistę domen zamiast akceptacji każdego adresu HTTPS
W serwerach wewnętrznych wiąż uchwyty stanu z użytkownikiem z tokenu
Zapytaj dostawców o wsparcie Enterprise-Managed Authorization dla waszego IdP

Powiązane materiały

Źródła

Chcesz przełożyć to na swój zespół?

Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.

Umów rozmowę Oferta dla firm

Więcej: MCP w firmie

← Wszystkie artykuły