Авторизация в MCP 2026-07-28: проверка издателя и изменения регистрации клиентов

Что это

По состоянию на 25 октября 2026 года. Изменения авторизации в 2026-07-28 касаются проверки издателя, регистрации и принадлежности учётных данных. Перед внедрением заново проверьте спецификацию авторизации для нужной редакции, правила регистрации и метаданные сервера авторизации. Client ID Metadata Documents (CIMD) появились не в этой редакции: они уже рекомендованы в списке изменений 2025-11-25. Новая редакция официально объявляет Dynamic Client Registration (DCR) устаревшим, сохраняя его для совместимости.

Сервер MCP — защищённый ресурс, клиент MCP получает доступ, а сервер авторизации выдаёт токены. Поэтому изменения могут затрагивать разные службы, даже если всеми ими управляет один оператор. Схема OAuth в MCP применяется к развёртываниям с HTTP; она не предписана в качестве механизма работы с учётными данными для stdio.

Почему это важно

Процесс авторизации должен сохранять связь с издателем, выбранным при его запуске. Иначе изменения конечных точек или неоднозначные записи о регистрации могут привести к использованию учётных данных на неверном сервере авторизации. CIMD также возлагает обязанности по получению документов и проверке перенаправлений: распознавание идентификатора клиента в виде URL само по себе не делает приложение доверенным.

Как применять

• Проверяйте ответы авторизации до обмена кода на токены. Клиенты сохраняют издателя из проверенных метаданных сервера вместе с верификатором PKCE для этой попытки авторизации. Серверам авторизации следует возвращать iss, и в таком случае они обязаны объявлять его поддержку. Клиенты сравнивают любой полученный iss с сохранённым значением на точное совпадение после декодирования формы, без нормализации URL. При несовпадении ответ отклоняется, в том числе если он сообщает об ошибке. Если метаданные объявляют поддержку параметра издателя, но iss отсутствует, отклоните ответ; если поддержка не объявлена и параметр не передан, спецификация разрешает продолжить.
• Привязывайте регистрационные учётные данные к издателю. Сохраняйте учётные данные предварительной регистрации или DCR под идентификатором выдавшего их сервера. Никогда не используйте их повторно у другого издателя. Зарегистрируйтесь на новом сервере; при несоответствии предварительной регистрации выдавайте ошибку. Это правило не привязывает самостоятельно размещённый идентификатор CIMD к конкретному издателю: спецификация регистрации прямо разрешает переносить такой URL-идентификатор без повторной регистрации.
• Соблюдайте правила выбора способа регистрации. Сначала используйте доступную предварительную регистрацию, затем CIMD, если его поддержка объявлена через client_id_metadata_document_supported, а затем поддерживаемый DCR как запасной вариант для совместимости. Документ CIMD доступен по HTTPS-адресу с путём и содержит client_id, client_name и redirect_uris. Его client_id должен совпадать с URL документа; проверяйте JSON и соответствие запрошенного перенаправления документу.
• Усильте защиту получения метаданных. При загрузке клиентских документов применяйте документированные меры против подделки запросов на стороне сервера. Рассмотрите политики доверия к доменам. Сам по себе CIMD не предотвращает выдачу одного приложения за другое при перенаправлениях на localhost; в соответствии с требованиями показывайте имя хоста перенаправления во время авторизации.
• Сохраняйте корректную работу старого DCR. Клиенты обязаны указывать подходящий application_type. Для нативных настольных приложений, CLI и приложений на localhost следует использовать native, для удалённых браузерных приложений — web. Выясняйте причины сбоев регистрации, а не ослабляйте проверки перенаправлений, чтобы ошибки исчезли.
• Сохраняйте существующий минимальный уровень безопасности. Проверяйте поддержку PKCE в метаданных, защищайте сохранённые токены и проверяйте, что входящие токены предназначены для этого ресурса MCP. Для вызовов вышестоящих API нужны отдельно выданные токены этих сервисов. Миграция регистрации не разрешает сквозную передачу токенов или удаление проверок согласия.

Подводные камни

Не описывайте DCR как уже удалённый механизм, а CIMD — как обязательный повсюду: его поддержка рекомендована. В качестве приёмочной проверки в тестовой среде предлагается проверить ответы с верным, несовпадающим и отсутствующим издателем, смену издателя и каждый сохранённый способ регистрации. Убедитесь, что отклонённые ответы никогда не доходят до обмена кода на токены. Эти проверки направлены на соответствие протоколу и не являются аудитом безопасности конкретного развёртывания авторизации.