MCP и OAuth: как подключить защищённый удалённый сервер

Когда удалённому MCP нужен OAuth?

MCP даёт приложению доступ к внешним инструментам. Для защищённого сервера, доступного по HTTP, OAuth в пользовательском сценарии позволяет человеку разрешить клиенту запросы от своего имени. Спецификация называет этот механизм необязательным: у локального сервера stdio, который клиент запускает как дочерний процесс, другая схема получения учётных данных. «OAuth 2.1» здесь — проект стандарта, на который опирается версия MCP; само по себе название не означает, что любой MCP-сервер уже поддерживает вход. s1

Представьте учебный инструмент read_sample, который возвращает синтетическую метку test-001. Цель проверки: после входа клиент видит разрешённый ответ, а без входа или с токеном для другого тестового ресурса сервер не выдаёт данные. Это предложенный сценарий для вашей среды, а не результат эксперимента Modelium. Реальные токены, документы и URL рабочего контура в отчёт не помещайте. s1 s3

Что подготовить перед подключением?

Зафиксируйте HTTPS-адрес своего MCP endpoint, адрес сервера входа и отдельную тестовую учётную запись с минимально необходимыми правами. Нужен клиент, который поддерживает авторизацию удалённого MCP по версии спецификации вашего сервера, а также два контролируемых вами тестовых ресурса, если проверяется отказ токену с неверным назначением. Требования к ОС и оборудованию задаёт установленное приложение; этот материал не предлагает разворачивать кластер или скачивать веса модели. Не открывайте учебный endpoint наружу только ради проверки. s1 s3

Как проходит вход по шагам?

1. Подключите адрес своего защищённого MCP endpoint в тестовом клиенте и выполните безвредный запрос. Если авторизация требуется, ожидайте ответ HTTP 401. Из заголовка WWW-Authenticate клиент берёт адрес метаданных ресурса; если его там нет, спецификация предписывает поиск по /.well-known/oauth-protected-resource с учётом пути endpoint. Метаданные содержат authorization_servers, а клиент затем получает описание выбранного сервера входа. Если адреса неожиданно ведут на чужой домен, остановите вход и выясните причину. s1 s2
2. Пройдите вход в браузере через совместимый клиент. Для такого потока клиент должен запрашивать токен с resource, указывающим точный адрес этого MCP-сервера, и передавать этот параметр и при авторизации, и при обмене кода на токен. PKCE — защита кода авторизации; спецификация требует поддержки PKCE клиентом и проверки объявления этой возможности сервером входа. Не подставляйте вручную токен от другого сервиса и не вставляйте его в URL. s1 s3
3. Повторите безвредный запрос через клиент. На своём стенде проверьте не только появление read_sample в перечне, но и фактический вызов с test-001: сохраните статус HTTP, запись серверного решения и ответ инструмента. Сверьте метку с входом; текст, который лишь написала языковая модель, не подтверждает вызов. Токен доступа клиент передаёт в заголовке Authorization: Bearer, а сервер проверяет его срок, права и назначение. s1 s3

Как проверить отказ и не раскрыть токен?

На собственном изолированном стенде запустите серверный интеграционный тест с тестовыми токенами от одного вашего сервера входа: один выпущен для ресурса A, второй — только для ресурса B. Проверьте, что A обрабатывает разрешённый запрос с первым токеном и возвращает HTTP 401 для второго, не вызывая инструмент; отказ должен быть виден в журнале A без записи самого токена. Это проверка сервера на неверное назначение токена, а не рекомендация клиенту посылать чужие токены: спецификация запрещает клиенту направлять на MCP-сервер токен другого ресурса. Если нет двух контролируемых тестовых ресурсов или возможности провести серверный тест, не объявляйте проверку назначения успешной. s1 s3

Отдельно повторите запрос без токена и с просроченным тестовым токеном: для обязательной авторизации или недействительного токена спецификация предусматривает HTTP 401. Недостаточные права при действительном токене — другой случай, HTTP 403; не лечите его подменой токена и не приписывайте HTTP 401 ошибке языковой модели. Зафиксируйте ожидаемый и фактический статусы, аудит решения и отсутствие выданных данных. Если тест не прошёл, не подключайте рабочие документы. s1

Граница: успешный вход не гарантирует безопасные действия всех инструментов или локальную работу модели. Сервер MCP должен проверять права на операции отдельно; пересылать полученный токен в сторонний API без отдельного обмена нельзя. После проверки входа откройте чек-лист прав MCP-инструментов и проведите разрешённый и запрещённый вызовы на синтетических данных. s3