Jakiej tożsamości powinno używać narzędzie MCP w systemie biznesowym

Nawet cztery tożsamości w jednym wywołaniu narzędzia

W zdalnym wywołaniu MCP biorą udział osoba korzystająca z asystenta, aplikacja kliencka działająca w jej imieniu, serwer MCP i system biznesowy za nim. Aktualna, opcjonalna specyfikacja autoryzacji MCP opisuje jeden odcinek tej drogi. Przy serwerze chronionym przez HTTP klient pobiera token dla serwera MCP, wskazując serwer w parametrze resource, a serwer musi sprawdzić, czy token wydano właśnie dla niego. Dla stdio specyfikacja przewiduje poświadczenia ze środowiska, czyli zwykle te, które skonfigurowała osoba uruchamiająca serwer.

Odcinek od serwera MCP do systemu biznesowego wykracza poza to, co standaryzuje MCP. Specyfikacja pozwala serwerowi występować wobec API wyższego poziomu jako klient OAuth z osobnym tokenem od tamtejszego serwera autoryzacji i zabrania przekazywania dalej otrzymanego tokenu. Sam przepływ MCP nie daje serwerowi praw użytkownika w systemie biznesowym.

Trzy opcje wywołania systemu docelowego

1. 1

   Delegowana zgoda w systemie biznesowym

   Użytkownik autoryzuje serwer MCP przez własny przepływ OAuth systemu biznesowego. O widoczności decydują reguły tego systemu, a jego log audytowy wskazuje konkretną osobę. Serwer musi przechowywać token dla każdego użytkownika i obsługiwać wygaśnięcie oraz cofnięcie dostępu.

2. 2

   Wymiana tokenów

   Usługa tokenów bezpieczeństwa wydaje nowy token dla systemu biznesowego jako odbiorcy, zgodnie z RFC 8693. RFC odróżnia impersonację, w której serwer staje się nieodróżnialny od użytkownika, od delegacji, w której serwer zachowuje własną tożsamość, działając w imieniu użytkownika. Delegacja pozostawia obie tożsamości widoczne dla audytu, o ile system biznesowy ją odczytuje.

3. 3

   Tożsamość serwisowa

   Serwer używa własnych poświadczeń. To pasuje do zadań harmonogramowanych i danych, które nie są przypisane do użytkownika. System biznesowy widzi tylko usługę, więc serwer sam egzekwuje reguły dotyczące użytkowników i loguje uwierzytelnioną tożsamość usługi lub workflow, a także osobę, która uruchomiła lub zatwierdziła akcję, jeśli taka jest. Właściciela każdego workflow zapisuje się osobno.

Rozpisana decyzja dla trzech hipotetycznych narzędzi

Tak mógłby wyglądać wybór dla asystenta działu kadr i zakupów. Systemy i narzędzia są wymyślone na potrzeby przykładu.

• get_leave_balance czyta dane urlopowe jednego pracownika. System kadrowy już kontroluje, kto widzi czyje dane, więc narzędzie używa delegowanego tokenu osoby pytającej. Tożsamość serwisowa zmusiłaby serwer do odtworzenia reguł widoczności działu kadr, a każda luka ujawniłaby dane innych osób.
• nightly_supplier_sync aktualizuje oceny ryzyka dostawców z zewnętrznego źródła. Za tym uruchomieniem nie stoi żadna osoba, więc uczciwym wyborem jest tożsamość serwisowa, która może zapisywać tylko te pola, z własnymi poświadczeniami i wskazanym właścicielem.
• create_purchase_request używa delegowanego tokenu osoby składającej wniosek, żeby ścieżki akceptacji i limity wydatków dotyczyły właściwej osoby. Wnioskujący potwierdza dokładną treść wniosku, a serwer lub system zakupowy weryfikuje to potwierdzenie, zanim cokolwiek zostanie utworzone.

Mieszany wynik jest czymś normalnym. Decyduj osobno dla każdego narzędzia i zapisz uzasadnienie obok definicji narzędzia, tam gdzie recenzenci będą go szukać.

Granice tokenów do sprawdzenia przed uruchomieniem

• Serwer MCP odrzuca tokeny wydane dla innego odbiorcy, także ważne tokeny twojego dostawcy tożsamości przeznaczone dla innej aplikacji
• Wywołania systemu docelowego nigdy nie używają tokenu przychodzącego, a każdy token do API wyższego poziomu jest pobierany dla tego API z najwęższymi scope'ami
• Tokeny użytkowników przechowywane przez serwer są zaszyfrowane, przypisane do użytkownika i wystawcy i usuwane, gdy użytkownik cofnie dostęp albo odejdzie z firmy
• Tokeny dostępu są krótkotrwałe, a tokeny odświeżania wydane klientom publicznym są rotowane, czego specyfikacja wymaga od serwerów autoryzacji
• Żaden token ani kod autoryzacji nie trafia do logów, śladów ani wyników narzędzi, bo specyfikacja traktuje tokeny buforowane lub logowane na serwerze jako ryzyko kradzieży
• Wyłączenie użytkownika u dostawcy tożsamości kończy jego dostęp przez wszystkie narzędzia w czasie, który zmierzyłeś

Gdzie pasuje autoryzacja zarządzana przez firmę

Wiele organizacji chce, żeby to dostawca tożsamości, a nie każdy pracownik z osobna, decydował, z których serwerów MCP wolno korzystać. Robi to oficjalne rozszerzenie Enterprise-Managed Authorization: klient pobiera od firmowego dostawcy tożsamości grant z asercją tożsamości, który uwzględnia zasady takie jak przynależność do grup, i wymienia go na token dostępu u serwera autoryzacji serwera MCP. Dostęp do serwerów MCP można wtedy przyznawać i odbierać centralnie.

Ważne są dwa ograniczenia. Rozszerzenie reguluje dostęp do serwera MCP, a nie prawa w systemach za nim, więc decyzję o wywołaniu systemu docelowego nadal trzeba podjąć. Wymaga też jawnego wsparcia po stronie klienta i nigdy nie jest domyślnie aktywne; projekt MCP prowadzi utrzymywane przez społeczność zestawienie wsparcia w klientach. Dla połączeń zupełnie bez użytkownika istnieje osobne oficjalne rozszerzenie dla grantu OAuth client credentials, które zaleca podpisane asercje JWT zamiast długowiecznych sekretów klienta.

Dobrym następnym krokiem jest jednostronicowa mapa tożsamości dla pierwszego planowanego serwera: każde narzędzie, tożsamość używana w systemie docelowym, uzasadnienie i kto może ją odebrać.

Tworzenie serwerów MCP