EN
Связаться
Глава 18

Авторизуйте remote MCP как защищенный resource server

Как только MCP-сервер доступен по HTTP, он становится защищаемым resource server, и протокол определяет для него OAuth-based authorization. Здесь важно не путать два вопроса. Authentication отвечает, кто вызывает сервер. Authorization отвечает, какие ресурсы и инструменты этому субъекту разрешены. Для локального stdio обычно достаточно доверенного launcher и ограниченного окружения; для удалённого - нет.

Поток авторизации проходит несколько шагов, и каждый нужен.

MCP Client
  1. читает protected resource metadata
  2. обнаруживает authorization server
  3. получает access token с нужным scope
  4. POST /mcp Authorization: Bearer …

MCP Server
  5. проверяет issuer, audience, expiry, signature
  6. сопоставляет subject/tenant/scopes с capability
  7. применяет object-level authorization в handler

Проверять права нужно не в одном месте, а слоями - и таблица показывает, где именно.

Уровень · Пример проверки · Где выполнять

  • Transport - TLS, Origin, размер body; Gateway/server edge
  • Token - Issuer, audience, expiry, signature; Auth middleware
  • Capability - Scope release:read; MCP handler boundary
  • Object - Service принадлежит tenant; Domain repository/service
  • Action - Deploy требует approval; Workflow/transaction service

Смысл слоёв в том, что ни один из них не заменяет другой. Transport-слой проверяет TLS, Origin и размер тела. Token-слой - issuer, audience, expiry, подпись. Capability-слой - есть ли у субъекта scope вроде release:read. Object-слой - принадлежит ли конкретный сервис его tenant. Action-слой - требует ли деплой отдельного approval.

Наивный дизайн ставит один админский токен, который открывает все инструменты всем хостам - и тогда компрометация одного клиента становится компрометацией всей поверхности возможностей. Профессиональный выдаёт короткоживущие токены конкретному MCP resource server, ограничивает scopes, связывает вызов с tenant и повторно проверяет каждый объект.

Server не должен принимать токен не для него. Проверка подписи без проверки audience недостаточна. Confused deputy на токене - реальная граница между удобной интеграцией и утечкой прав. Не пересылайте upstream-токен в downstream-API, если у того другой audience.

Права мы закрыли на уровне протокола. Но у MCP есть отдельный класс угроз - на стыке недоверенного текста и реальных действий, - и его стоит разобрать отдельно.

Проверка знаний

Сервер проверил подпись токена. Достаточно ли этого, чтобы его принять?

Ссылки