Внутри обвязки: привязка issuer в OAuth для MCP и почему безопасность протокола держится на сравнении строк

Сначала три числа, потом объясню. Первое: поле issuer в документе метаданных OAuth представляет собой одну строку. Второе: этим летом Atlassian, Context7 и Home Assistant успели отдать метаданные авторизации MCP, где эта строка не совпадала с URL, с которого документ был получен, и строгие клиенты отказывались подключаться. Третье: исправление, которое теперь входит в спецификацию MCP, по сути звучит как «сравните строки и отклоните ответ, если они различаются». Вот и весь механизм. А закрывает он одну из самых неприятных атак в OAuth, mix-up-атаку, которую сама схема развёртывания MCP делает ещё более естественной.

Это материал из серии «Внутри обвязки», поэтому полезем в саму механику: что за проблема с привязкой issuer, какие потоки она затрагивает и чего пакет спецификации 2026-07-28 требует от тех, кто строит MCP-клиент или сервер. Изменения транспорта без состояния в том же релизе забрали заголовки. Усилению авторизации достались шесть SEP и почти никакого внимания. На мой взгляд, приоритеты перевёрнуты. Если ваши MCP-серверы держат настоящие учётные данные, именно эта часть определяет, не отдаст ли запутавшийся клиент токен не той стороне.

Ключевые выводы - MCP переворачивает классическую форму OAuth: один клиент общается со множеством серверов авторизации, обнаруживаемых во время выполнения. Именно против такой топологии и создавались механизмы защиты от mix-up-атак. - Пакет спецификации 2026-07-28 включает шесть SEP. Два самых важных: SEP-2468 (проверять параметр iss в ответах авторизации по RFC 9207) и SEP-2352 (привязывать зарегистрированные учётные данные каждого клиента к issuer, который их выдал). - Это не теория. Этим летом конечные точки MCP Atlassian и Context7 уже отдавали в реальных развёртываниях метаданные с несовпадающим issuer, из-за чего строгие клиенты ломались. Спецификация догоняет ошибки, которые уже происходят в продакшене. - Проверка iss сейчас рекомендована и движется к обязательной. Добавьте её сегодня и воспринимайте отсутствие iss у сервера, который должен его поддерживать, как причину отклонить ответ, а не как мелочь. - Даже после полного внедрения этот пакет укрепляет только аутентификацию между клиентом и сервером. Идентичность агента, авторизация каждого запроса, происхождение делегирования и аудит остаются вне протокола. Это по-прежнему ваша задача.

Что произошло

21 мая 2026 года сопровождающие MCP зафиксировали кандидата в релиз спецификации 2026-07-28. Финальная версия вышла 28 июля, а сопровождающие SDK с тех пор работают в десятинедельном окне валидации. Большинство комментариев было посвящено переходу к модели без состояния. Под ним, как подробно разбирает Tigera, находится пакет из шести предложений по улучшению спецификации, усиливающих слой OAuth:

Три более хозяйственных SEP, 2207, 2350 и 2351, выглядят как уточнения. Но в спецификациях авторизации уточнения важны: если два SDK не согласны, где находится документ метаданных, это сбой совместимости, а не сноска. Несущая пара здесь 2468 и 2352. Обе отвечают на один вопрос: как клиент понимает, с каким сервером он на самом деле разговаривает?

Пакет спецификации MCP 2026-07-28 включает шесть SEP, усиливающих OAuth: проверку issuer (2468), учётные данные, привязанные к issuer (2352), объявление типа клиента при динамической регистрации клиентов (837), а также документированный токен обновления (2207), накопление scope (2350) и поведение обнаружения (2351), согласно разбору Tigera. Кандидат в релиз был зафиксирован 21 мая, а финальная спецификация вышла 28 июля 2026 года.

Модель уязвимости: один клиент, много серверов авторизации

Классический OAuth предполагает много клиентов и один сервер авторизации: тысячи приложений, один поставщик идентичности, один issuer для токенов. Mix-up-атаки, при которых клиента заставляют приписать ответ авторизации не тому серверу, долго оставались нишевой проблемой, потому что большинство клиентов общались только с одним issuer.

MCP разворачивает эту схему наоборот. Один клиент, хост-приложение, общается со множеством MCP-серверов. За каждым может стоять свой сервер авторизации, обнаруживаемый во время выполнения, причём регистрация часто происходит на лету через динамическую регистрацию клиентов. Авторы спецификации говорят прямо: SEP по проверке issuer нацелен на «класс mix-up-атак, который более распространён в типичной для MCP схеме с одним клиентом и множеством серверов», как цитирует Tigera. Когда клиент одновременно держит регистрации у десятка серверов авторизации, атакующему не нужно ломать криптографию. Достаточно заставить клиента приписать ответ не тому серверу.

Схема выглядит так. Хост вашего агента находится посреди потока с честным сервером A, когда приходит ответ, который на самом деле поступил от контролируемого атакующим сервера B. Без проверки issuer клиент может завершить обмен с B, допустить утечку кода авторизации или принять токены, выданные B, и затем предъявить их дальше. RFC 9207, исправление классического OAuth от 2021 года, добавил явный параметр iss в ответы авторизации, чтобы клиент мог отклонять всё, что пришло от неожиданного issuer. SEP-2468 переносит это требование в MCP. SEP-2352 закрывает более тихую половину проблемы: учётные данные. Раньше клиент мог держать идентификатор клиента, выданный issuer A, а после миграции ресурса к issuer B предъявить B старые учётные данные от A. Иногда это работало, а «иногда работает» не то свойство, которое хочется видеть в системе авторизации. Поэтому 2352 требует хранить регистрации отдельно для каждого сервера авторизации, привязывать их к значению issuer и заново регистрироваться при миграции.

Это не первая попытка закрыть этот класс проблем. В версии спецификации от 18.06.2025 Resource Indicators (RFC 8707) стали обязательными, чтобы токены выпускались для одного конкретного сервера, а спецификация авторизации MCP уже запрещает принимать токены, предназначенные для других ресурсов, или передавать их дальше по цепочке. Пакет 2026-07-28 продолжает ту же линию: меньше доверия по умолчанию, больше явных привязок. Если вы читали мой материал MCP против API, это цена той гибкости, о которой я там писал. Обнаружение во время выполнения делает MCP композиционным, но заодно создаёт такие вопросы идентичности.

Топология MCP «один клиент, много серверов» как раз и является схемой, на которую нацелены mix-up-атаки: атакующий не ломает криптографию, а заставляет клиент приписать ответ или учётные данные неправильному серверу авторизации. SEP-2468 привязывает ответы к issuer через параметр iss из RFC 9207; SEP-2352 привязывает зарегистрированные учётные данные к серверу, который их выдал, согласно разбору Tigera и RFC 9207.

Спецификация догоняет ошибки из продакшена

Если всё это звучит абстрактно, то зря. Этим летом строка issuer уже ломалась в реальных развёртываниях MCP, и строгие клиенты на этом спотыкаются.

В июле пользователи клиента opencode обнаружили, что OAuth к MCP-серверу Rovo от Atlassian ломается на этапе обнаружения. Метаданные защищённого ресурса корректно указывали сервер авторизации конкретного арендатора, но документ метаданных, который тот отдавал, объявлял общий issuer https://auth.atlassian.com вместо пути конкретного арендатора, с которого документ был получен. RFC 8414, раздел 3.3, требует, чтобы значение issuer в точности совпадало с URL, использованным для получения метаданных, за вычетом суффикса .well-known. Поэтому строгая проверка opencode правильно отклоняла документ и полностью блокировала вход. Это была ошибка соответствия спецификации на стороне Atlassian, подтверждённая на реальных конечных точках. В июне конечная точка MCP Context7 столкнулась с родственной ошибкой: объявленный сервер авторизации и issuer в метаданных на поддомене Clerk не совпадали, и официальный MCP Go SDK отказывался продолжать поток. Метаданные Home Assistant вообще не содержали поле issuer, ломая MCP-клиенты уже другим способом.

Ни один из этих трёх случаев не был эксплуатацией mix-up-уязвимости. Это были сбои совместимости. Но в этом и суть. То же сравнение строк, которое блокирует поддельный сервер атакующего, блокирует и небрежно настроенный настоящий сервер. Поэтому экосистема скоро станет заметно менее терпимой к метаданным, которые всегда были неправильными, но раньше сходили с рук. Разбор mix-up-атак от WorkOS хорошо формулирует эксплуатационный вывод: многие библиотеки OAuth до сих пор не включают проверку RFC 9207 по умолчанию. Там же CVE-2026-59208 приводится как пример ошибки, которую можно было бы полностью остановить, если ограничивать поиск учётной записи подтверждённым issuer, а не глобально сопоставлять утверждение sub. Ссылку на этот CVE я бы воспринимал как сообщение WorkOS, а не как факт, который я независимо подтвердил, но сам защитный принцип в любом случае стандартный.

Этим летом реальные MCP-развёртывания уже падали на проверке issuer: MCP-сервер Rovo от Atlassian отдаёт метаданные, где issuer не совпадает с URL арендатора, с которого документ был получен (обсуждение #39332 в opencode); конечная точка Context7 объявляла один сервер авторизации, а его метаданные указывали другой (обсуждение #2723 Context7); Home Assistant вообще не указывал issuer. RFC 8414, раздел 3.3, требует точного совпадения issuer с URL получения, поэтому строгие клиенты корректно отклоняли все три варианта.

Что должны сделать разработчики

Если вы сопровождаете MCP-клиент:

1. Проверяйте iss в каждом ответе авторизации уже сейчас. Отклоняйте значение, которое не совпадает с issuer текущего потока. Если сервер заявляет поддержку RFC 9207, но не передаёт параметр, тоже отклоняйте ответ. Спецификация прямо говорит, что в будущей версии отказ при отсутствии iss станет ожидаемым поведением, поэтому лучше считать это обязательным уже сегодня.

2. Разделяйте состояние регистрации по серверу авторизации. Каждый идентификатор клиента, секрет и токен обновления должен храниться вместе со значением issuer, который его выдал. Если метаданные защищённого ресурса начинают указывать на новый сервер авторизации, регистрируйтесь заново. Никогда не переиспользуйте старые учётные данные.

3. Объявляйте application_type при динамической регистрации клиентов. SEP-837 закрывает класс ошибок, когда настольный или CLI-клиент по умолчанию считается web и отклоняется из-за URI перенаправления на localhost. Одно поле, и целый класс реальных сбоев исчезает.

4. Ограничивайте поиск учётных записей подтверждённым issuer. Утверждение sub должно сопоставляться только с аккаунтами внутри пространства имён того issuer, который вы действительно проверили. Никогда не ищите его глобально.

Если вы управляете MCP-сервером или стоящим перед ним сервером авторизации, отдавайте метаданные, где issuer в точности равен URL, с которого они получаются, включая путь арендатора; реализуйте метаданные защищённого ресурса по RFC 9728 и продолжайте проверять, что токены выпущены именно для вашего ресурса. А если вы самостоятельно размещаете агентов, подключая их к растущему списку MCP-серверов, начинает работать простая арифметика флота: N агентов на M серверов означает N × M регистраций, привязанных к issuer. При десяти агентах это ещё таблица. При сотне уже реестр, а спецификация ничего не говорит о реестрах. Здесь платформа остаётся вашей ответственностью.

Разработчикам необходимо проверять iss в ответах авторизации, отклоняя несовпадения и, там где параметр должен поддерживаться, его отсутствие; хранить учётные данные отдельно по issuer и заново регистрироваться после миграции; объявлять application_type при динамической регистрации клиентов; ограничивать поиск учётной записи проверенным issuer, согласно анализу SEP от Tigera и рекомендациям WorkOS по mix-up-атакам. Ожидается, что SDK уровня 1 добавят поддержку в течение десятинедельного окна валидации спецификации.

Чего спецификация по-прежнему не решает

Перечитайте пакет и обратите внимание, что объединяет все шесть SEP: они укрепляют обмен между одним OAuth-клиентом и одним сервером авторизации. Это было необходимо. Но, как прямо пишет Tigera, токен аутентифицирует клиента, а не агента. Двести агентов за одним хостом используют одну общую клиентскую идентичность. Привязка issuer ничего не говорит о том, какой именно агент, от чьего имени и на основании какого решения стоит за клиентом. Области доступа дают допуск, а не политику на каждый запрос. Цепочки делегирования, где агент вызывает агента, а тот вызывает сервер, могут быть безупречными с точки зрения OAuth на каждом переходе и при этом совершенно неподотчётными от начала до конца. И пакет не требует от кого-либо записывать эту историю. Для протокола это правильное ограничение области, для предприятия ответ неполный.

Я говорю это не для того, чтобы принизить работу. MCP без проверки issuer был примерно как HTTP без проверки сертификата, и эта дыра теперь закрывается. Но четыре пробела, идентичность агента, авторизация каждого запроса, происхождение делегирования и аудит, принадлежат уже слою управления. Они не появятся просто потому, что вы дождётесь следующей версии спецификации. Это те же вопросы, которые я разбираю с клиентами в теме управления агентами, и они обеспечиваются средой вокруг агента или не обеспечиваются вообще.

Частые вопросы

В чём проблема привязки OAuth issuer в MCP?

MCP-клиенты общаются со множеством серверов авторизации, которые обнаруживаются во время выполнения. Поэтому они уязвимы для mix-up-атак, когда ответ или учётные данные приписываются неправильному серверу. Спецификация 2026-07-28 исправляет это, требуя от клиентов проверять параметр iss в ответах авторизации (SEP-2468 с принятием RFC 9207) и привязывать каждые зарегистрированные учётные данные к их issuer (SEP-2352).

Это уязвимость самого MCP?

Это класс уязвимостей, который стал более вероятным из-за схемы развёртывания протокола и теперь закрыт на уровне спецификации. Ошибки, замеченные этим летом в продакшене, когда Atlassian, Context7 и Home Assistant отдавали метаданные с неправильным или отсутствующим issuer, были ошибками реализации. Но они хорошо показывают, насколько хрупкой была модель без строгой проверки. Теперь строгая валидация становится базовой нормой.

Какие потоки затронуты?

Потоки кода авторизации для любого клиента, зарегистрированного более чем у одного сервера авторизации; динамическая регистрация клиентов между серверами; использование учётных данных после миграции ресурса между серверами авторизации; обнаружение метаданных через документы .well-known. Развёртывания с одним сервером не были главным риском. Риск создаёт многосерверная топология, которую приносят агенты.

Когда это станет обязательным?

Спецификация 2026-07-28 уже финальная. Поддержка в SDK появляется в десятинедельном окне валидации, которое началось после фиксации кандидата в релиз в мае, а текст спецификации прямо говорит, что в будущей версии ожидается отклонение ответов без iss. Всё, что вы строите сейчас, лучше проектировать так, будто это требование уже обязательное.

Итог

Безопасность OAuth в значительной степени состоит из скучного сравнения строк с очень нескучными последствиями, и MCP наконец дошёл до этого факта. Пакет 2026-07-28 переносит исправление пятилетней давности из OAuth в протокол, где схема «один клиент, много серверов» сделала его срочным, как раз в тот момент, когда реальные развёртывания начали массово проваливать эту проверку. Обновите SDK, проверяйте iss, привязывайте регистрации. А потом задайте вопрос, на который спецификация правильно не пытается ответить: когда выданный вами токен используется для вызова инструмента, который вы бы никогда не одобрили, агентом, которого вы не можете даже назвать, кто это остановит и где останется запись? Ответ приходит не из спецификации. Его даёт обвязка, которую вы строите вокруг неё.

Если вы разбираетесь с авторизацией и идентичностью в развёртывании MCP, я регулярно обсуждаю такие задачи с клиентами. Связаться со мной.

Источники

• Tigera, «Усиление авторизации MCP: что исправляют шесть новых OAuth SEP и чего они всё ещё не решают»: https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (опубликовано 28.07.2026, просмотрено 29.08.2026)

• WorkOS, «Mix-up-атаки OAuth и RFC 9207: проверка issuer, которая так и не дошла до обмена токенами»: https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (опубликовано 20.07.2026, просмотрено 29.08.2026)

• Model Context Protocol, спецификация авторизации: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (опубликовано 25.11.2025, просмотрено 29.08.2026)

• RFC Editor, RFC 9207, «Идентификация issuer сервера авторизации OAuth 2.0»: https://www.rfc-editor.org/rfc/rfc9207.html (опубликовано 16.12.2021, просмотрено 29.08.2026)

• Репозиторий opencode, обсуждение #39332, «MCP OAuth: авторизация Atlassian не работает из-за несовпадения issuer по RFC 8414»: https://github.com/anomalyco/opencode/issues/39332 (опубликовано 28.07.2026, просмотрено 29.08.2026)

• Репозиторий Context7, обсуждение #2723, «Несовпадение issuer в метаданных OAuth для конечной точки MCP»: https://github.com/upstash/context7/issues/2723 (опубликовано 05.06.2026, просмотрено 29.08.2026)

• Home Assistant Core, обсуждение #147059, отсутствие issuer в метаданных OAuth: https://github.com/home-assistant/core/issues/147059 (опубликовано 17.06.2025, просмотрено 29.08.2026)

• Репозиторий modelcontextprotocol/modelcontextprotocol: https://github.com/modelcontextprotocol/modelcontextprotocol (просмотрено 29.08.2026)