Авторизация в MCP: по действующей спецификации сначала ответь «кто ты»

Введение

MCP (Model Context Protocol) — стандартная «проводка» между ИИ-приложениями и внешними инструментами: MCP-хост (например, Claude Code, Claude Desktop или VS Code) создаёт один клиент на каждый MCP-сервер, а серверы предоставляют три примитива — tools, resources, prompts. В этом материале разбираем его модель авторизации по официальной действующей спецификации авторизации MCP (версия 2026-07-28; 6 октября 2026 г. проверено, что /specification/latest перенаправляет сюда). (Анализ продуктов по состоянию на 6 октября 2026 г.)[1]

[1] [2]

Авторизация остаётся опциональной

Действующая спецификация: Authorization is OPTIONAL. Реализации на HTTP SHOULD следовать этой спецификации; локальные серверы на STDIO SHOULD NOT идти этим OAuth-потоком, а вместо этого берут учётные данные из окружения. Обратите внимание: это SHOULD NOT, а не техническая невозможность, — безопасно ли локальное, зависит от изоляции процессов и хранения учётных данных, и спецификация оставляет это implementer'ам.[2]

[2]

Три роли

Действующая спецификация вводит раздел «Roles» с тремя сторонами: защищённый MCP-сервер — это OAuth 2.1 resource server; MCP-клиент — это OAuth 2.1 client, делающий запросы к защищённым ресурсам от имени resource owner; authorization server при необходимости взаимодействует с пользователем и выпускает access tokens, и может быть размещён вместе с resource server или как отдельная сущность — детали его реализации вне scope этой спецификации. «Кто выпускает токены» и «кто их получает» формально разделены.[2]

[2]

Привязка resource и audience

Действующая спецификация требует от клиентов реализовать Resource Indicators по RFC 8707: параметр resource MUST присутствовать и в authorization-, и в token-запросах, указывая канонический URI MCP-сервера, для которого предназначен токен; сервер как resource server MUST проверить, что access tokens выпущены именно для него как intended audience, принимая только токены, выпущенные его собственным authorization server для его собственных ресурсов, и MUST NOT принимать или транзитить никакие другие токены. Токены привязаны к ресурсам: один токен — одно место.[2]

[2]

DCR устарел

В действующей спецификации Dynamic Client Registration (DCR) устарел и сохранён лишь для обратной совместимости; authorization servers и MCP-клиенты SHOULD поддерживать OAuth Client ID Metadata Documents. Перед инициацией потока авторизации клиенты MUST получить client ID одним из трёх механизмов — Client ID Metadata Documents, предрегистрация или DCR — в порядке приоритета, определённом спецификацией.[2]

[2]

Scope-челленджи и step-up

Действующая спецификация детализирует обработку нехватки прав: серверы MAY включать параметр scope в заголовок WWW-Authenticate ответа 401, указывая требуемые разрешения; когда токен отклонён из-за нехватки scope, сервер SHOULD ответить 403 с insufficient_scope — обратите внимание, это случай нехватки scope; недействительные или просроченные токены по-прежнему получают 401. Клиент переавторизуется с расширенным набором scope через step-up поток и повторяет запрос.[2]

Нужно различать два разных «человека»: step-up переавторизация идёт OAuth-потоком авторизации, который клиенты, действующие от имени пользователя, SHOULD попытаться пройти по спецификации, — и сам этот поток может требовать взаимодействия с пользователем; протокол авторизации допускает, а в ряде случаев требует интерактивную авторизацию. Но это не то же самое, что «обязательное подтверждение человеком каждого вызова инструмента». Первое — механизм внутри протокола авторизации, второе — policy вызовов на уровне хоста. Это не одно и то же.[2]

[2]

Handshake 401

Когда авторизация требуется, а клиент её ещё не доказал, сервер отвечает HTTP 401, после чего клиент инициирует поток OAuth 2.1; токены идут в заголовке Authorization, никогда — в query string URI (требование Section 5 OAuth 2.1, на которое ссылается действующая спецификация). Клиенты точно сопоставляют полученный iss с заранее записанным issuer; отсутствие iss требует отклонения ответа только тогда, когда сервер авторизации заявляет о поддержке этого параметра (RFC 9207).[2]

[2]

Корпоративный ответ

Корпоративное расширение (с независимым версионированием) превращает IdP организации в авторитетного принимающего решения: сотрудники входят один раз, а IdP по политике организации решает, к каким MCP-серверам им можно; согласно документации расширения, в развёртываниях, реализующих и поддерживающих расширение, отзыв происходит один раз на уровне IdP и немедленно действует на всех клиентах. Практического тестирования реализаций не проводилось; не гарантируется, что все MCP-развёртывания ведут себя так. Индивидуальная авторизация разумна для потребителей; в корпорациях она создаёт трение и бреши.[3]

[3]

Комментарий

1. Протокол стандартизирует только handshake, а не политику. Раздел «Roles» явно выводит реализацию authorization server за scope спецификации — MCP даже не решает за вас, «кто выпускает токены». Это честный дизайн: оценивая развёртывание, смотрите на сторону authorization server, а не на сам провод.

2. Устаревание DCR показывает конвергенцию протокола. Сдвиг от «динамически регистрировать всё» к «сначала декларировать метаданные идентичности» переносит доверие с переговоров в рантайме на декларацию при регистрации. Удобство уступает аудируемости — типичная траектория зреющего протокола.

3. «От чьего имени» остаётся первоосновой. Действующая спецификация сохраняет различие в разделе step-up: «клиенты, действующие от имени пользователя» и «client_credentials клиенты» идут разными потоками [2]. Действие под видом пользователя и действие от имени самого приложения подразумевают совершенно разную логику аудита и отзыва — при выборе спрашивайте сначала это, потом про scope.

4. Протокол авторизации не равен подтверждению каждого действия. Scope-челленджи и step-up — механизмы разрешений внутри протокола, причём step-up может предполагать взаимодействие с пользователем; но «обязательное подтверждение человеком каждого вызова инструмента» — другое дело, это policy уровня хоста. Проектируя агентский publishing-пайплайн, надо разделять слой протокола («можно ли использовать этот токен») и слой политик («одобрен ли этот вызов») — как написание, ревью и подпись релиза никогда не должны быть одними руками.

5. Четыре вопроса практикам (действующая спецификация). Кто authorization server (вместе с resource server или независимо)? Реально ли enforced привязка resource/audience? Какова стратегия scope-челленджей сервера (как используется 403)? Какой из трёх механизмов регистрации клиентов используется? Не можете ответить — пока не подключайте production-данные.

[2]

Что пока утверждать нельзя

Насколько полно хосты и клиенты реализуют действующую спецификацию (практически не тестировалось);

Реальный прогресс устаревания DCR;

Реальный уровень безопасности конкретных MCP-серверов (по их собственной документации и аудитам).