Авторизация в MCP: OAuth 2.1, метаданные ресурса, CIMD

Когда нужна авторизация#

Авторизация в MCP необязательна. Спецификация описывает её для HTTP-транспортов: сервер, который открывает закрытые данные или действия, использует OAuth 2.1. Локальные серверы stdio получают доступ другими путями, например через переменные окружения.

Сервер MCP в схеме OAuth — это сервер ресурсов. Он не выдаёт токены сам, а указывает, какой сервер авторизации их выдаёт, и проверяет предъявленные токены.

Как проходит авторизация#

Клиент отправляет запрос серверу MCP без токена.
Сервер отвечает ошибкой 401 и заголовком WWW-Authenticate с адресом документа метаданных защищённого ресурса (RFC 9728).
Клиент читает этот документ и узнает адрес сервера авторизации, затем получает метаданные самого сервера авторизации (RFC 8414 или OpenID Connect Discovery).
Клиент получает идентификатор клиента: предпочтительно через документ метаданных клиента (CIMD).
Пользователь входит в браузере и даёт согласие. Клиент использует код авторизации с PKCE и передаёт параметр resource в запросах авторизации и токена.
Клиент проверяет параметр iss в ответе (RFC 9207), обменивает код на токен и вызывает сервер MCP с токеном.
Сервер проверяет, что токен выдан именно для него, и отклоняет все остальные.

Стандарты, на которые опирается MCP#

Стандарты авторизации в ревизии 2026-07-28
Стандарт	Что делает в MCP	Требование
RFC 9728, метаданные защищённого ресурса	Сервер MCP сообщает, где его сервер авторизации	Сервер обязан публиковать, клиент обязан использовать
RFC 8414, метаданные сервера авторизации	Клиент узнаёт адреса и возможности сервера авторизации	Сервер авторизации поддерживает его или OpenID Connect Discovery
RFC 8707, указатели ресурса	Привязывает токен к одному серверу MCP	Клиент обязан передавать resource
RFC 9207, идентификатор издателя	Защищает от подмены сервера авторизации	Клиент обязан сверять iss, если он есть в ответе
CIMD, документы метаданных клиента	Идентификатор клиента — адрес его описания	Предпочтительный способ регистрации клиента
RFC 7591, динамическая регистрация устарело	Регистрация клиента во время подключения	Признана устаревшей, остаётся для совместимости
PKCE	Защита кода авторизации от перехвата	Используется в потоке кода авторизации

Регистрация клиентов#

Раньше клиенты регистрировались на серверах авторизации динамически (DCR). Это порождало проблемы с учётом клиентов и безопасностью. Ревизия 2026-07-28 официально признаёт DCR устаревшим и предлагает CIMD: идентификатором клиента служит адрес документа с его описанием, а сервер авторизации сам забирает нужные данные.

DCR остаётся для совместимости. Клиенты, которые его используют, обязаны указывать тип приложения (application_type), чтобы серверы авторизации не отвергали локальные адреса возврата у настольных и консольных приложений. Учётные данные клиента привязываются к выдавшему их серверу авторизации: их нельзя использовать с другим сервером, а при его смене клиент обязан зарегистрироваться заново.

Что проверить на своём сервере#

Список составлен по требованиям спецификации; перед внедрением сверяйтесь с её текстом.

Сервер публикует документ метаданных защищённого ресурса и указывает в нём хотя бы один сервер авторизации.
Ответ 401 содержит заголовок WWW-Authenticate с адресом этого документа.
Сервер проверяет, что токен выдан именно для него (audience), и не принимает чужие.
Токены, коды авторизации и проверочные значения PKCE не попадают в журналы.
Не передавайте принятый токен дальше другим сервисам: безопасность такой передачи разбирается в разделе спецификации о безопасности авторизации.

Что изменилось в ревизии 2026-07-28#

Динамическая регистрация клиентов признана устаревшей в пользу CIMD.
Серверы авторизации должны возвращать параметр iss, клиенты обязаны его сверять.
Учётные данные клиента привязаны к выдавшему их серверу авторизации.
Клиенты обязаны указывать application_type при динамической регистрации.

Остальные изменения протокола — в разделе «Изменения и устаревшее».