# Авторизация в MCP

> Как клиент MCP получает доступ к защищённому серверу: порядок шагов, стандарты и что изменилось в ревизии 2026-07-28.

Ревизия MCP 2026-07-28 · проверено 03.10.2026 · https://mcpprotocol.ru/authorization/

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

Авторизация в MCP необязательна. Спецификация описывает её для HTTP-транспортов: сервер, который открывает закрытые данные или действия, использует [OAuth 2.1](https://mcpprotocol.ru/glossary/#oauth). Локальные серверы stdio получают доступ другими путями, например через переменные окружения.

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

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

1. Клиент отправляет запрос серверу MCP без токена.
2. Сервер отвечает ошибкой 401 и заголовком `WWW-Authenticate` с адресом документа [метаданных защищённого ресурса](https://mcpprotocol.ru/glossary/#prm) (RFC 9728).
3. Клиент читает этот документ и узнает адрес сервера авторизации, затем получает метаданные самого сервера авторизации (RFC 8414 или OpenID Connect Discovery).
4. Клиент получает идентификатор клиента: предпочтительно через [документ метаданных клиента](https://mcpprotocol.ru/glossary/#cimd) (CIMD).
5. Пользователь входит в браузере и даёт согласие. Клиент использует код авторизации с PKCE и передаёт параметр [resource](https://mcpprotocol.ru/glossary/#resource-indicators) в запросах авторизации и токена.
6. Клиент проверяет параметр [iss](https://mcpprotocol.ru/glossary/#iss) в ответе (RFC 9207), обменивает код на токен и вызывает сервер MCP с токеном.
7. Сервер проверяет, что токен выдан именно для него, и отклоняет все остальные.

## Стандарты, на которые опирается 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](https://mcpprotocol.ru/glossary/#dcr)). Это порождало проблемы с учётом клиентов и безопасностью. Ревизия 2026-07-28 официально признаёт DCR устаревшим и предлагает [CIMD](https://mcpprotocol.ru/glossary/#cimd): идентификатором клиента служит адрес документа с его описанием, а сервер авторизации сам забирает нужные данные.

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

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

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

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

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

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

Остальные изменения протокола — в разделе [«Изменения и устаревшее»](https://mcpprotocol.ru/changes/).