# Регистрация клиента: CIMD и DCR

> Три способа получить идентификатор клиента в MCP 2026-07-28 - Client ID Metadata Documents, предварительная регистрация и устаревшая Dynamic Client Registration

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

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

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

Источник - страница [Client Registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration) спецификации.

## Какой способ выбрать

| Способ | Когда подходит | Статус |
|---|---|---|
| Client ID Metadata Documents (CIMD) | клиент и сервер раньше не были знакомы - самый частый случай | рекомендуется поддерживать |
| предварительная регистрация | между клиентом и сервером уже есть отношения | рекомендуется поддерживать клиентам |
| Dynamic Client Registration (DCR) | сервер авторизации не умеет CIMD | устарела, поддержка по желанию |

Клиенту, который умеет всё, следует действовать в таком порядке:

1. использовать заранее зарегистрированные данные, если они есть для этого сервера;
2. использовать CIMD, если сервер авторизации объявил `client_id_metadata_document_supported`;
3. использовать DCR, если сервер авторизации объявил `registration_endpoint`;
4. попросить пользователя ввести данные клиента.

## Client ID Metadata Documents

Идентификатором клиента служит адрес HTTPS. По этому адресу лежит документ JSON с описанием клиента. Сервер авторизации сам загружает документ, когда встречает такой идентификатор. Основа - черновик IETF [OAuth Client ID Metadata Document](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00).

```json title="Документ метаданных клиента"
{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Example MCP Client",
  "client_uri": "https://app.example.com",
  "redirect_uris": [
    "http://127.0.0.1:3000/callback",
    "http://localhost:3000/callback"
  ],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}
```

Требования к клиенту:

- документ размещается по адресу HTTPS;
- адрес в `client_id` использует схему `https` и содержит путь;
- в документе есть как минимум `client_id`, `client_name` и `redirect_uris`;
- значение `client_id` в документе в точности совпадает с адресом документа.

Требования к серверу авторизации:

- обязан проверить, что `client_id` в документе в точности совпадает с адресом;
- обязан сверять адрес возврата из запроса с адресами в документе;
- обязан проверить, что документ - корректный JSON с обязательными полями;
- ему следует загружать документ, встретив идентификатор в виде адреса, и кэшировать его с учётом заголовков HTTP.

Свою поддержку сервер авторизации объявляет в метаданных:

```json
{ "client_id_metadata_document_supported": true }
```

Документ метаданных сам по себе не защищает от подделки клиента с адресом возврата на `localhost`. Спецификация требует от сервера авторизации ясно показывать узел адреса возврата и рекомендует дополнительно предупреждать, когда адреса возврата ведут только на `localhost`. Загружая чужой документ, серверу авторизации следует учитывать риск подделки запросов со стороны сервера (SSRF).

## Предварительная регистрация

Клиенту следует поддерживать заранее выданные данные. Вариантов два:

- идентификатор клиента зашит в клиент для конкретного сервера авторизации;
- пользователь сам регистрирует клиента у сервера авторизации и вводит полученные данные в интерфейсе клиента.

## Dynamic Client Registration

Динамическая регистрация по [RFC 7591](https://datatracker.ietf.org/doc/html/rfc7591) объявлена устаревшей. Новым реализациям следует использовать CIMD. DCR остаётся для совместимости с серверами авторизации, которые CIMD не поддерживают. По [реестру устаревшего](https://mcpdoc.ru/protocol/deprecations/) её могут удалить не раньше первой редакции, вышедшей 28 июля 2027 или позже.

При динамической регистрации клиент обязан указывать подходящее значение `application_type`. Если его пропустить, сервер авторизации с OpenID Connect посчитает клиента веб-приложением, и адрес возврата на `localhost` может быть отклонён.

| Клиент | Значение |
|---|---|
| настольное или мобильное приложение, утилита командной строки, локальное веб-приложение на `localhost` | `native` |
| веб-приложение на удалённом узле | `web` |

Клиент обязан быть готов к отказу в регистрации из-за ограничений на адрес возврата; ему следует показать понятную ошибку.

## Привязка к серверу авторизации

Учётные данные клиента действуют только у того сервера авторизации, который их выдал.

| Способ регистрации | Что делать при смене сервера авторизации |
|---|---|
| предварительная регистрация | данные хранятся по идентификатору издателя; при несовпадении следует показать ошибку, а не пробовать чужие данные |
| DCR | данные хранятся по идентификатору издателя; использовать их с другим сервером нельзя, нужна новая регистрация |
| CIMD | ничего: идентификатор - собственный адрес клиента, он переносим между серверами авторизации |

Смену сервера авторизации клиент замечает по обновлённым [метаданным защищённого ресурса](https://mcpdoc.ru/auth/discovery/).

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

- [Метаданные и обнаружение](https://mcpdoc.ru/auth/discovery/) - где клиент видит, какие способы поддерживает сервер авторизации.
- [Модель авторизации](https://mcpdoc.ru/auth/) - что происходит после регистрации.