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

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

Источник - страница Client Registration спецификации.

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

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

Идентификатором клиента служит адрес HTTPS. По этому адресу лежит документ JSON с описанием клиента. Сервер авторизации сам загружает документ, когда встречает такой идентификатор. Основа - черновик IETF OAuth Client ID Metadata Document.

{
  "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.

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

{ "client_id_metadata_document_supported": true }

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

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

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

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

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

Смену сервера авторизации клиент замечает по обновлённым метаданным защищённого ресурса.

• Метаданные и обнаружение - где клиент видит, какие способы поддерживает сервер авторизации.
• Модель авторизации - что происходит после регистрации.