Как диагностировать перекрёстную OAuth-сессию двух MCP-серверов с общим issuer: resource metadata, audience и безопасная переавторизация.
Один issuer не равен одному ресурсу
Составьте локальную таблицу по каждому MCP-серверу: нейтральная метка, URL ресурса, адрес Protected Resource Metadata и общий issuer. Не копируйте client_id, секреты, токены и внутренние домены в заметку. Спецификация MCP требует, чтобы клиент обнаруживал авторизационные серверы через metadata защищённого ресурса и передавал resource в запросах авторизации и токена. RFC 8707 задаёт resource indicator, из которого сервер авторизации определяет целевую audience. Поэтому одинаковый issuer может обслуживать разные защищённые ресурсы, а повторное использование одной сессии между ними нельзя считать корректным только из-за общего домена авторизации.
Матрица «resource — token — response»
Для сервера A и сервера B запишите четыре результата без значений секретов: metadata обнаружена, resource передан, audience соответствует ожидаемой, запрос принят или отклонён. Спецификация MCP требует токен, предназначенный конкретному MCP server, и допускает ответ 401 для недействительного или просроченного токена. RFC 8707 описывает ограничение audience как защиту от использования токена не тем ресурсом. Поэтому 401 audience mismatch может быть корректной реакцией принимающего сервера, даже если пользователь успешно прошёл вход. Важно локализовать, какой клиентский сеанс был выбран для каждой строки, не декодируя и не публикуя bearer token в сторонних сервисах.
Безопасный эксперимент с раздельной авторизацией
Начните с резервной копии обезличенной конфигурации MCP без секретов. Отключите сервер B, авторизуйте и проверьте одну нейтральную read-only команду сервера A. Затем завершите именно эту сессию штатным способом клиента, включите B и повторите отдельно. Последний прогон выполните с обоими серверами, не меняя issuer или server URL. Если изолированные прогоны работают, а совместный возвращает audience mismatch, результат указывает на разделение клиентского состояния, но ещё не раскрывает внутреннюю реализацию. Не удаляйте системное хранилище учётных данных целиком и не отзывайте организационные OAuth-приложения без полномочий администратора.
Что передать разработчикам без токенов
Укажите версии IDE и расширения Copilot, число MCP-серверов, факт общего issuer и разных resource, порядок авторизации, код 401 и обезличенный результат audience match. Приложите домены только если они публичны; внутренние адреса замените A и B. Не отправляйте Authorization header, refresh token, client secret, cookies и полный конфигурационный файл. Полезна временная шкала: подключён A, подключён B, выполнен запрос к A, получен ответ от A или B. GitHub документирует настройку MCP в Copilot Chat для JetBrains, а спецификация и RFC подтверждают границы токенов. Публичная ветка служит сигналом повторяющейся боли, но не доказательством уязвимости или масштаба.
Материал подготовлен редакцией VOne с применением ИИ для матрицы ресурсов; требования вручную сверены по спецификации MCP, RFC 8707 и официальной документации GitHub.
Источники и проверка
- Model Context Protocol — Authorization проверено 2026-08-07
- RFC 8707 — Resource Indicators for OAuth 2.0 проверено 2026-08-07
- GitHub Copilot — Use MCP servers in JetBrains проверено 2026-08-07
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.