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

Источник: https://modelium.tech/zhurnal/mcp-oauth-udalennyy-server/

Для защищённого удалённого MCP-сервера клиент получает адрес сервера авторизации из метаданных, проходит вход через браузер и посылает выданный ему токен доступа в заголовке запроса. Сервер обязан проверить не только действительность токена, но и то, что тот предназначен именно ему. Ниже — порядок проверки на собственном изолированном стенде, а не подтверждение безопасности конкретного сервиса: Modelium такой вход не запускал.

**Инженерный гайд, не домашний рецепт.** Нужны собственный изолированный HTTPS MCP-сервер с авторизацией, работающий сервер входа (authorization server), тестовый клиент и право смотреть HTTP-статусы и серверный журнал. Инструкция сверена со спецификацией MCP от 28 июля 2026 года на закреплённой ревизии `db4bfcff`; Modelium не поднимал эти серверы и не проверял готовую интеграцию. ОС, модель и память определяются вашим стеком: этот протокольный тест сам по себе не запускает языковую модель. [s1](#src-s1) [s3](#src-s3)

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

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

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

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

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

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

- **Подключите адрес своего защищённого MCP endpoint в тестовом клиенте** и выполните безвредный запрос. Если авторизация требуется, ожидайте ответ HTTP 401. Из заголовка `WWW-Authenticate` клиент берёт адрес метаданных ресурса; если его там нет, спецификация предписывает поиск по `/.well-known/oauth-protected-resource` с учётом пути endpoint. Метаданные содержат `authorization_servers`, а клиент затем получает описание выбранного сервера входа. Если адреса неожиданно ведут на чужой домен, остановите вход и выясните причину. [s1](#src-s1) [s2](#src-s2)

- **Пройдите вход в браузере через совместимый клиент.** Для такого потока клиент должен запрашивать токен с `resource`, указывающим точный адрес *этого* MCP-сервера, и передавать этот параметр и при авторизации, и при обмене кода на токен. PKCE — защита кода авторизации; спецификация требует поддержки PKCE клиентом и проверки объявления этой возможности сервером входа. Не подставляйте вручную токен от другого сервиса и не вставляйте его в URL. [s1](#src-s1) [s3](#src-s3)

- **Повторите безвредный запрос через клиент.** На своём стенде проверьте не только появление `read_sample` в перечне, но и фактический вызов с `test-001`: сохраните статус HTTP, запись серверного решения и ответ инструмента. Сверьте метку с входом; текст, который лишь написала языковая модель, не подтверждает вызов. Токен доступа клиент передаёт в заголовке `Authorization: Bearer`, а сервер проверяет его срок, права и назначение. [s1](#src-s1) [s3](#src-s3)

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

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

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

**Граница:** успешный вход не гарантирует безопасные действия всех инструментов или локальную работу модели. Сервер MCP должен проверять права на операции отдельно; пересылать полученный токен в сторонний API без отдельного обмена нельзя. После проверки входа откройте [чек-лист прав MCP-инструментов](/zhurnal/mcp-bezopasnost-instrumentov/) и проведите разрешённый и запрещённый вызовы на синтетических данных. [s3](#src-s3)

## Источники

1. [MCP specification 2026-07-28 — Authorization](https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/db4bfcff3d60f5df01a21bdf6b78f7012cac4634/docs/specification/2026-07-28/basic/authorization/index.mdx) — получено 2026-10-22
2. [MCP specification 2026-07-28 — Authorization Server Discovery](https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/db4bfcff3d60f5df01a21bdf6b78f7012cac4634/docs/specification/2026-07-28/basic/authorization/authorization-server-discovery.mdx) — получено 2026-10-22
3. [MCP specification 2026-07-28 — Authorization Security Considerations](https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/db4bfcff3d60f5df01a21bdf6b78f7012cac4634/docs/specification/2026-07-28/basic/authorization/security-considerations.mdx) — получено 2026-10-22