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

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

Страница: https://mcpdoc.ru/auth/discovery/
Указатель сайта: https://mcpdoc.ru/llms.txt

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

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

Источник - страница [Authorization Server Discovery](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/authorization-server-discovery) спецификации.

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

Сервер MCP обязан реализовать [RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728). В документе метаданных обязано быть поле `authorization_servers` хотя бы с одним сервером авторизации.

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

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

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

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

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

```http title="Ответ сервера MCP без токена"
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](https://datatracker.ietf.org/doc/html/rfc8414) и 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](https://mcpdoc.ru/auth/client-registration/) |
| `registration_endpoint` | сервер поддерживает динамическую регистрацию |
| `authorization_response_iss_parameter_supported` | сервер включает `iss` в ответ авторизации |
| `scopes_supported` | перечень областей доступа |

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

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

- [Модель авторизации](https://mcpdoc.ru/auth/) - весь путь от ответа `401` до запроса с токеном.
- [Регистрация клиента](https://mcpdoc.ru/auth/client-registration/) - что делать после того, как сервер авторизации найден.