# Модель авторизации MCP > Как устроена авторизация MCP в редакции 2026-07-28 - роли OAuth 2.1, шаги получения токена, параметр resource, правила обращения с токенами, области доступа и коды ответов Страница: https://mcpdoc.ru/auth/ Указатель сайта: https://mcpdoc.ru/llms.txt Авторизация MCP построена на OAuth 2.1. Сервер MCP выступает защищённым ресурсом, клиент MCP - клиентом OAuth, токены выдаёт отдельный сервер авторизации. Авторизация необязательна и описана только для HTTP: локальный сервер на stdio берёт учётные данные из окружения. описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026 Источник - раздел [Authorization](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) спецификации. ## Когда это применяется | Транспорт | Что говорит спецификация | |---|---| | HTTP | реализации следует соответствовать этому разделу | | stdio | этому разделу следовать не следует; учётные данные берутся из окружения | | свой транспорт | обязан следовать принятым правилам безопасности своего протокола | Сама авторизация для реализации MCP необязательна. Клиент и сервер могут договориться и о собственном способе. ## Три роли | Роль OAuth 2.1 | Кто это в MCP | Что делает | |---|---|---| | сервер ресурсов | сервер MCP | принимает запросы с токеном доступа и проверяет его | | клиент | клиент MCP | получает токен и обращается к серверу от имени владельца ресурса | | сервер авторизации | отдельная служба | общается с пользователем и выдаёт токены | Сервер авторизации может работать вместе с сервером MCP или быть отдельной системой. Как он устроен внутри, спецификация MCP не определяет. ```mermaid sequenceDiagram participant C as Клиент MCP participant M as Сервер MCP participant A as Сервер авторизации C->>M: запрос без токена M-->>C: 401 и адрес метаданных ресурса C->>M: метаданные защищённого ресурса C->>A: метаданные сервера авторизации Note over C,A: пользователь даёт согласие, PKCE, параметр resource A-->>C: код авторизации C->>A: обмен кода на токен A-->>C: токен доступа C->>M: запрос с токеном M-->>C: ответ ``` ## Что на чём основано Спецификация берёт подмножество существующих стандартов. Это важно, чтобы не путать правило MCP с правилом OAuth. | Стандарт | Для чего | |---|---| | OAuth 2.1 (черновик IETF `draft-ietf-oauth-v2-1-13`) | основа: роли, выдача токенов, PKCE | | [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728) | метаданные защищённого ресурса: как сервер MCP сообщает, где его сервер авторизации | | [RFC 8414](https://datatracker.ietf.org/doc/html/rfc8414) | метаданные сервера авторизации | | [RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) | параметр `resource`: для какого ресурса запрашивается токен | | [RFC 9207](https://datatracker.ietf.org/doc/html/rfc9207) | параметр `iss`: какой сервер авторизации ответил | | [RFC 6750](https://datatracker.ietf.org/doc/html/rfc6750) | передача токена в заголовке | | [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591) | динамическая регистрация клиента (в MCP устарела) | | Client ID Metadata Documents (черновик IETF) | регистрация клиента по адресу документа | OAuth 2.1 и Client ID Metadata Documents на момент проверки - черновики IETF, а не утверждённые RFC. Спецификация MCP ссылается на конкретные их версии. ## Обязательное по спецификации MCP 1. Сервер авторизации обязан реализовать OAuth 2.1 с мерами защиты и для закрытых, и для открытых клиентов. 2. Сервер MCP обязан реализовать метаданные защищённого ресурса по RFC 9728. Клиент обязан использовать их, чтобы найти сервер авторизации. 3. Сервер авторизации обязан дать хотя бы один способ обнаружения: метаданные по RFC 8414 или OpenID Connect Discovery. Клиент обязан поддерживать оба. 4. Клиент обязан получить идентификатор клиента одним из трёх способов до начала авторизации. 5. Клиент обязан реализовать PKCE и убедиться по метаданным, что сервер авторизации его поддерживает. Подробности первых трёх пунктов - на странице [«Метаданные и обнаружение»](https://mcpdoc.ru/auth/discovery/), четвёртого - на странице [«Регистрация клиента»](https://mcpdoc.ru/auth/client-registration/). ## Параметр `resource` Клиент обязан указывать, для какого сервера MCP ему нужен токен. Параметр `resource`: - обязан присутствовать и в запросе авторизации, и в запросе токена; - обязан называть сервер MCP, с которым клиент собирается работать; - обязан содержать канонический адрес сервера. | Адрес | Годится | |---|---| | `https://mcp.example.com/mcp` | да | | `https://mcp.example.com` | да | | `https://mcp.example.com:8443` | да | | `mcp.example.com` | нет: не указана схема | | `https://mcp.example.com#fragment` | нет: есть фрагмент | Клиент отправляет параметр всегда, даже если сервер авторизации его не поддерживает. ## Обращение с токеном ```http title="Запрос с токеном" POST /mcp HTTP/1.1 Host: mcp.example.com Authorization: Bearer eyJhbGciOiJIUzI1NiIs... ``` | Кто | Требование | |---|---| | клиент | передаёт токен в заголовке `Authorization` в каждом запросе HTTP | | клиент | не помещает токен в строку запроса адреса | | клиент | не отправляет серверу MCP токены, выданные другим сервером авторизации | | сервер MCP | проверяет, что токен выдан именно для него | | сервер MCP | на недействительный или просроченный токен отвечает `401` | | сервер MCP | не принимает и не передаёт дальше никакие другие токены | Последнее правило запрещает передачу токена насквозь. Если сервер MCP обращается к стороннему API, он действует там как отдельный клиент OAuth со своим токеном. Токен, полученный от клиента MCP, туда передавать нельзя. ## Области доступа Серверу MCP следует сообщать нужные области доступа в заголовке `WWW-Authenticate`. ```http title="Ответ 401 с подсказкой" 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"` и перечнем нужных областей. Клиенту, который действует от имени пользователя, следует запросить новый токен: объединить ранее запрошенные области с новыми, чтобы не потерять прежние права. Число повторов следует ограничивать. ## Коды ответов | Статус | Когда | |---|---| | `401` | нужна авторизация или токен недействителен | | `403` | областей доступа недостаточно | | `400` | запрос авторизации составлен неверно | ## Проверка ответа авторизации Серверу авторизации следует включать в ответ параметр `iss` по RFC 9207. Клиент до перехода обязан запомнить издателя из проверенных метаданных, а получив ответ - сверить. | Сервер объявил поддержку `iss` | `iss` в ответе | Действие клиента | |---|---|---| | да | есть | сравнить с запомненным издателем | | да | нет | отклонить ответ | | нет | есть | сравнить с запомненным издателем | | нет | нет | продолжить | Сравнение - посимвольное, без приведения адресов к общему виду. Спецификация сама предупреждает: в одной из следующих редакций включение `iss` для сервера авторизации, как ожидается, станет обязательным. ## Токены обновления Клиент не должен рассчитывать, что получит токен обновления: это решает сервер авторизации. Полученный токен клиент обязан хранить и передавать защищённо. Серверу MCP не следует указывать `offline_access` среди требуемых областей. ## Расширения авторизации Доступ без пользователя (OAuth Client Credentials) и корпоративное управление доступом (Enterprise-Managed Authorization) не входят в основную спецификацию. Это отдельные необязательные [расширения](https://mcpdoc.ru/protocol/extensions/). ## Что читать дальше - [Метаданные и обнаружение](https://mcpdoc.ru/auth/discovery/) - как клиент находит сервер авторизации. - [Регистрация клиента](https://mcpdoc.ru/auth/client-registration/) - три способа получить идентификатор клиента. - [Защита сервера](https://mcpdoc.ru/security/server/) - требования безопасности к серверу с авторизацией.