Метаданные и обнаружение сервера авторизации

Как клиент MCP находит сервер авторизации в редакции 2026-07-28 - метаданные защищённого ресурса по RFC 9728, порядок адресов well-known и проверка издателя

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

Источник - страница Authorization Server Discovery спецификации.

Шаг 1. Метаданные защищённого ресурса

Сервер MCP обязан реализовать RFC 9728. В документе метаданных обязано быть поле authorization_servers хотя бы с одним сервером авторизации.

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

Способ	Как выглядит
заголовок `WWW-Authenticate`	в ответе `401` параметр `resource_metadata` содержит адрес документа
адрес well-known	документ лежит по известному адресу на узле сервера

Варианты адреса well-known для сервера по адресу https://example.com/public/mcp:

с путём сервера: https://example.com/.well-known/oauth-protected-resource/public/mcp
в корне: https://example.com/.well-known/oauth-protected-resource

Клиент обязан поддерживать оба способа. Если в ответе 401 есть resource_metadata, берётся он; если нет - клиент строит адреса well-known в указанном порядке.

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

Несколько серверов авторизации

В authorization_servers может быть несколько серверов. Выбирает клиент. Каждый из них - независимый сервер авторизации:

клиент обязан вести отдельное состояние для каждого: идентификатор клиента, учётные данные, токены;
клиент не должен считать, что данные от одного подойдут другому.

Шаг 2. Метаданные сервера авторизации

MCP не вводит собственный адрес для метаданных сервера авторизации. Используются адреса из RFC 8414 и OpenID Connect Discovery. Клиент обязан пробовать их по порядку.

Издатель с путём, например https://auth.example.com/tenant1:

Порядок	Адрес
1	`https://auth.example.com/.well-known/oauth-authorization-server/tenant1`
2	`https://auth.example.com/.well-known/openid-configuration/tenant1`
3	`https://auth.example.com/tenant1/.well-known/openid-configuration`

Издатель без пути, например https://auth.example.com:

Порядок	Адрес
1	`https://auth.example.com/.well-known/oauth-authorization-server`
2	`https://auth.example.com/.well-known/openid-configuration`

Проверка издателя

Получив документ, клиент обязан проверить: значение issuer в нём обязано в точности совпадать с идентификатором издателя, по которому строился адрес. Если не совпадает, документ использовать нельзя.

Пример из спецификации: документ, полученный с https://attacker.example/.well-known/oauth-authorization-server, в котором записано "issuer": "https://honest.example", обязан быть отклонён.

Что клиент ищет в метаданных

Поле	Зачем
`code_challenge_methods_supported`	признак поддержки PKCE; если поля нет, клиент обязан отказаться продолжать
`client_id_metadata_document_supported`	сервер принимает Client ID Metadata Documents
`registration_endpoint`	сервер поддерживает динамическую регистрацию
`authorization_response_iss_parameter_supported`	сервер включает `iss` в ответ авторизации
`scopes_supported`	перечень областей доступа

Сервер авторизации, который даёт только OpenID Connect Discovery, обязан включать code_challenge_methods_supported в метаданные, чтобы быть совместимым с MCP.

Что читать дальше

Модель авторизации - весь путь от ответа 401 до запроса с токеном.
Регистрация клиента - что делать после того, как сервер авторизации найден.