Модель авторизации MCP

описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026

Источник - раздел Authorization спецификации.

Сама авторизация для реализации MCP необязательна. Клиент и сервер могут договориться и о собственном способе.

Сервер авторизации может работать вместе с сервером MCP или быть отдельной системой. Как он устроен внутри, спецификация MCP не определяет.

Спецификация берёт подмножество существующих стандартов. Это важно, чтобы не путать правило MCP с правилом OAuth.

OAuth 2.1 и Client ID Metadata Documents на момент проверки - черновики IETF, а не утверждённые RFC. Спецификация MCP ссылается на конкретные их версии.

1. Сервер авторизации обязан реализовать OAuth 2.1 с мерами защиты и для закрытых, и для открытых клиентов.
2. Сервер MCP обязан реализовать метаданные защищённого ресурса по RFC 9728. Клиент обязан использовать их, чтобы найти сервер авторизации.
3. Сервер авторизации обязан дать хотя бы один способ обнаружения: метаданные по RFC 8414 или OpenID Connect Discovery. Клиент обязан поддерживать оба.
4. Клиент обязан получить идентификатор клиента одним из трёх способов до начала авторизации.
5. Клиент обязан реализовать PKCE и убедиться по метаданным, что сервер авторизации его поддерживает.

Подробности первых трёх пунктов - на странице «Метаданные и обнаружение», четвёртого - на странице «Регистрация клиента».

Клиент обязан указывать, для какого сервера MCP ему нужен токен. Параметр resource:

• обязан присутствовать и в запросе авторизации, и в запросе токена;
• обязан называть сервер MCP, с которым клиент собирается работать;
• обязан содержать канонический адрес сервера.

Клиент отправляет параметр всегда, даже если сервер авторизации его не поддерживает.

POST /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

Последнее правило запрещает передачу токена насквозь. Если сервер MCP обращается к стороннему API, он действует там как отдельный клиент OAuth со своим токеном. Токен, полученный от клиента MCP, туда передавать нельзя.

Серверу MCP следует сообщать нужные области доступа в заголовке WWW-Authenticate.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

Клиенту следует запрашивать только то, что нужно для работы:

1. взять области из параметра scope ответа 401, если он есть;
2. если его нет - взять scopes_supported из метаданных ресурса; если и его нет, не указывать scope совсем.

Если уже выданного токена не хватает для операции, серверу следует ответить 403 с error="insufficient_scope" и перечнем нужных областей. Клиенту, который действует от имени пользователя, следует запросить новый токен: объединить ранее запрошенные области с новыми, чтобы не потерять прежние права. Число повторов следует ограничивать.

Серверу авторизации следует включать в ответ параметр iss по RFC 9207. Клиент до перехода обязан запомнить издателя из проверенных метаданных, а получив ответ - сверить.

Сравнение - посимвольное, без приведения адресов к общему виду.

Клиент не должен рассчитывать, что получит токен обновления: это решает сервер авторизации. Полученный токен клиент обязан хранить и передавать защищённо. Серверу MCP не следует указывать offline_access среди требуемых областей.

Доступ без пользователя (OAuth Client Credentials) и корпоративное управление доступом (Enterprise-Managed Authorization) не входят в основную спецификацию. Это отдельные необязательные расширения.

• Метаданные и обнаружение - как клиент находит сервер авторизации.
• Регистрация клиента - три способа получить идентификатор клиента.
• Защита сервера - требования безопасности к серверу с авторизацией.