Аутентификация в MCP в 2026: как было, как есть и как будет

Пару лет назад мы масштабно столкнулись с совершенно новой технологией, которая пришла вместе с развитием агентов и LLM — MCP. Она заточена на то, чтобы дать модели интерфейс для общения с какой‑либо системой, программой или сервером. Изначально MCP были локальными и скромными: «запусти калькулятор», «проверь календарь», «удали лишние фоточки из галереи». Но очень быстро они доросли до remote‑серверов: вставляешь в Claude адрес своего MCP, и он сразу понимает, что сервер умеет, куда подключаться и как с ним общаться. Большое спасибо за это протоколу, который в ноябре 2024 придумали в Anthropic. И как только MCP стал remote, аутентификация перестала быть опциональной. Именно про это сегодня и пойдет речь.

«Добавь OAuth в свой MCP‑сервер» может звучать как ограниченная по объему задача. Но это не так. Вы целитесь в движущуюся мишень: спека меняла роль сервера дважды за примерно 15 месяцев, через три недели прилетает новая версия, а крупные агенты сегодня реализуют каждый по‑своему. Эта статья — карта: что стандарт говорит сейчас, как мы к этому пришли, что грядет и что каждый большой агент на самом деле от вас требует.

Сегодня

Аутентификация в MCP — это то, как remote MCP‑сервер понимает, кто к нему пришел, прежде чем запускать tool. Ваш сервер не выдает собственных кредов, он обычный OAuth resource server, который валидирует токен, выписанный отдельным авторизационным сервером.

На момент написания (начало июля 2026) актуальной стабильной версией считается 2025–11-25, а модель аутентификации — OAuth 2.1. Аутентификация в целом опциональна, но если сервер ее делает, спека разделяет работу между двумя сторонами: MCP‑сервер — обычный OAuth resource server, а выписка токенов принадлежит отдельному authorization server  (Keycloak, Hydra, Okta, Entra).

Флоу начинается с отказа. Неаутентифицированный запрос получает 401, и этот 401 несет в себе всё, что нужно клиенту, чтобы разобраться самому: где живет resource metadata, с каким авторизационным сервером говорить, какие скоупы просить. Дальше агент знает весь маршрут: как зарегистрироваться, где взять токен, как его обновить и как предъявить.

Как было

История короткая по таймлайну, но насыщенная в изменениях.

В самой первой версии спеки (2024–11-05) не было никакого упоминания авторизации. Делайте кто на что горазд, удачи.

Версия от 2025–03-26 исправила эту ошибку и завезла не абы что, а настоящий OAuth 2.1, но с одним не лучшим решением: MCP‑сервер сам был авторизационным сервером. Дефолтные /authorize, /token и /register должны были быть на MCP сервере (resource server). Хотите за ним Keycloak, Hydra или любой настоящий IdP — всё должно проксироваться через ваш MCP‑сервер. Самодостаточно, соблазнительно и неправильно.

С этого момента умные ребята из разных auth‑компаний начали публиковать статьи, которые разносят весь этот дизайн в пух и прах:

• Aaron Parecki (Okta), «Let’s fix OAuth in MCP» (апрель 2025). Его главная претензия: спека заставляла MCP‑сервер БЫТЬ авторизационным сервером. Дискавери был устроен так, что клиент забирал OAuth‑метадату прямо с base URL самого MCP‑сервера, а значит, у resource server’а не было выбора — приходилось играть еще и роль IdP. «That’s not necessary», как он сам это описал. Предложил он почти слово в слово то, что потом и приняли: RFC 9728 Protected Resource Metadata (сервер просто указывает на свой AS), делегацию выписки токенов внешнему AS и Dynamic Client Registration для саморегистрации клиентов.

• Christian Posta, «The updated MCP OAuth spec is a mess». Тут претензий целый вагон. Спека смешивает роли AS и RS. Сервер вынужден становиться stateful: выписывай свои токены, храни маппинг своих токенов на токены третьих сторон, следи за их жизненным циклом — прощай, stateless и горизонтальное масштабирование. Каждый MCP‑сервер обязан выставлять собственный /.well-known/oauth-authorization-serverвместо одного центрального IdP на компанию. А делегация к третьим сторонам тянет за собой token chaining со всеми его радостями: задержки распространения отзыва, timing‑атаки. Комментарий под статьей подытожил developer experience: «Just setting this up looks daunting, let alone doing so securely».

Критику формализовали быстро. PR #338 перестроил auth‑спеку, а PR #734 добавил resource indicators из RFC 8707.

И, о боги, жалобы были услышаны. Ревизия 2025–06-18 привезла тектоническое изменение (которое, кстати, нехило так ломает обратную совместимость): MCP‑сервер стал resource server’ом. Если быть совсем дотошным: RFC 9728 + RFC 8707 стали MUST (клиент шлет resource, сервер валидирует audience токена), а token passthrough запретили напрочь.

На этом большая драма закончилась, и мы подобрались к 2025–11-25 — сегодняшней стабильной ревизии. Но и тут не без сюжетного поворота: DCR, который казался неприкасаемым, заменили на CIMD (Client ID Metadata Documents) как дефолтный способ регистрации. Разница сводится к тому, кто таскает метадату клиента. При DCR клиент сам пушил свою метадату на AS при регистрации; при CIMD AS сам идет и забирает ее по URL, который контролирует клиент. Мотивация — безопасность и упрощение, как это работает — покажу в следующем разделе.

Для тех, кто волновался: DCR оставили в спеке для нас, холопов, заботящихся об обратной совместимости.

Как есть

Скрытый текст

Пройдемся по шагам:

1. Клиент стучится в сервер без токена и получает 401. В ответе может лежать хедер WWW-Authenticate с resource_metadata. С версии 2025–11-25 этот хедер опционален: если его нет, клиент сам пробует /.well-known/oauth-protected-resource.

2. Клиент забирает Protected Resource Metadata и читает оттуда authorization_servers — список авторизационных серверов, которым доверяет этот ресурс.

3. Клиент идет к AS за его метадатой (RFC 8414 или OIDC Discovery) и запускает обычный OAuth 2.1 флоу с PKCE, передавая параметр resource (RFC 8707), чтобы токен был привязан к конкретному MCP‑серверу.

4. С полученным токеном клиент возвращается к серверу. Тот проверяет подпись и audience и только после этого начинает отвечать по существу.

Основное отличие от предыдущей ревизии — одна стрелка: GET https://client.example/cimd.json. При DCR клиент сам пушил эти данные в registration endpoint; при CIMD AS вытягивает их по URL. Проще говоря, регистрация переехала с push‑модели на pull‑модель. По заверению разработчиков протокола, это убивает client impersonation: больше не получится сделать ничего «неприятного» с redirect_uris, потому что они обязаны жить в документе с метадатой на сервере, который контролирует клиент, и AS забирает и валидирует их именно оттуда. Атакующему, который хочет подменить redirect на свой, теперь нужен контроль над этим хостингом, а не просто запрос на регистрацию. У Auth0 есть хороший разбор, какие именно атаки это закрывает.

Как будет: версия от июля 2026

Tl;dr: протокол продолжает меняться, и мы вынуждены меняться с ним.

Следующая ревизия сейчас в статусе release candidate, запланирована на 28 июля 2026, контент заморожен с 21 мая. В части аутентификации ничего драматичного, просто «секьюры» решили подзакрутить гаек. Стандартный OAuth‑хардеринг, поломок совместимости в auth‑главе не ожидается:))

Для дотошных, все шесть изменений:

1. Клиенты обязаны валидировать поле iss в ответе авторизации (RFC 9207, SEP-2468). Это защита от mix‑up‑атак, которые в MCP особенно актуальны: один клиент ходит сразу к куче серверов и авторизационных серверов. Без проверки issuer злонамеренный AS может сыграть man‑in‑the‑middle между клиентом и честным AS.

2. Клиенты должны декларировать application_type при OIDC‑style динамической регистрации (SEP-837). Зачем? Чтобы AS понимал, что перед ним desktop‑ или CLI‑клиент, и не заворачивал его localhost redirect_uri как «подозрительный web».

3. Креды клиента привязываются к issuer того AS, который их выдал (SEP-2352). Один resource server может сидеть за несколькими авторизационными серверами, и креды от одного не подойдут к другому. Если ресурс переезжает на другой AS, клиент перерегистрируется, а не переигрывает старые креды.

4. Настоящие инструкции, как запрашивать refresh token у OIDC‑style авторизационных серверов (SEP-2207) — раньше спека оставляла это как упражнение для читателя.

5. Scope accumulation при step‑up consent (SEP-2350). Это про ситуацию, когда клиент по ходу сессии просит дополнительные права: сначала read, а через час пользователь дернул тул, которому нужен write. Раньше было неясно, что происходит с уже выданными скоупами при таком втором консенте. Теперь прописано: скоупы накапливаются. Новый консент добавляет права к старым, а не перетирает их.

6. Уточнение, как строить discovery URL с .well-known‑суффиксом (SEP-2351), чтобы клиенты перестали гадать, в какое место пути его подставлять.

А вот за пределами аутентификации ревизия огромная. Протокол становится стейтлес: хедер Mcp-Session-Id и хендшейк initialize уходят, так что любой инстанс сервера может ответить на любой запрос без sticky sessions.

This release contains breaking changes. We don’t intend for that to be the norm.

© разработчики спеки MCP. Ну что ж, поживем — увидим

Как большие агенты соблюдают всё это (середина 2026)

Это была история становления современной аутентификации в MCP. Теперь давайте пройдемся по популярным агентам и посмотрим, насколько хорошо они ей следуют. Спойлер: НЕ ОЧЕНЬ.

Не исключено, что картина сдвинется к моменту прочтения, но на начало июля 2026 она выглядит как таблица ниже.

Из хорошего: почти все поддерживают современный стандарт (шатаут OpenAI и их Responses API MCP tool с технологиями прошлой геологической эры).

Из плохого: одну и ту же спеку все читают по‑разному. Кто‑то гоняет весь OAuth‑флоу за пользователя, кто‑то просто ждет готовый bearer‑токен и умывает руки. Кто‑то требует DCR, кто‑то топит за CIMD, кто‑то живет на статических кредах и IAM.

Подробная матрица (все ячейки актуализированы на начало июля 2026):

И заметки, которые не влезли в таблицу:):

• Claude API MCP connector: только HTTP‑транспорт, только tools. Вы передаете authorization_token, рефреш — ваша проблема.

• claude.ai / Desktop: static_bearer явно не поддерживается.

• OpenAI Responses API: вы передаете authorization, токен не хранится, никакого discovery, просто добротный bearer.

• ChatGPT / Apps SDK: отвергает machine‑to‑machine, API‑key и customer mTLS auth.

• Gemini / Google Cloud: принимает ровно то, что ChatGPT отвергает, включая client credentials и API keys.

• VS Code / Copilot: возит с собой встроенные провайдеры GitHub и Entra.

• Cursor: перерегистрировал своего DCR‑клиента на каждом реконнекте (upd: починили в v3.2).

• Perplexity: единственный с явным режимом «без ауса»; внутренности флоу не задокументированы.

Что из этого стоит вынести:

• Несколько ревизий спеки живы в проде одновременно. Responses API от OpenAI вообще не делает discovery, вы просто передаете bearer, VS Code сидит на 2025–06-18, а Anthropic, ChatGPT и Google ссылаются на 2025–11-25.

• И Anthropic, и OpenAI умудряются жить сразу с двумя противоположными моделями внутри одной компании. У каждого есть API‑продукт в стиле «принеси свой токен»: Claude API MCP connector и Responses API принимают готовый bearer, а флоу и рефреши — твоя проблема. И у каждого же есть полноценный клиент (claude.ai и ChatGPT), который сам проходит весь путь от 401 до токена. Сервер, написанный под первую модель, не заведется во второй без доработок, и наоборот.

• Есть прямые противоречия. ChatGPT отвергает machine‑to‑machine и API‑key auth; Google требует ровно это для некоторых сервисов. Регистрация расколота на четыре лагеря: DCR, CIMD, статические креды, IAM.

• Ну и на сладенькое, реальный issue из Claude Code: anthropics/claude‑code#46640. Сервер без аутентификации работает в CLI и падает с 404 в VS Code‑расширении. Один вендор, один сервер, два разных результата.

Что мне не нравится и что хотелось бы поменять

• Мне, как человеку, который зарабатывает разработкой публичного API, очень не нравятся поломки обратной совместимости. Каждая создает фронт миграционной работы, а тех, кто не может себе позволить это время, превращает в заложников старых технологий.

• OAuth 2.1 — стандарт, и всем без разницы: полмира до сих пор сидит на API keys.

• Спека обновляется слишком часто. Приходится в самом буквальном смысле держать руку на пульсе.

• Очень мало авторизационных серверов могут полностью поддержать OAuth 2.1 для MCP из коробки (насколько я могу судить, реально близок только Keycloak). Всем остальным нужны врапперы, прокладки и синяя изолента. Коробочного решения нет, и это заметно.

С OAuth 2.1 есть отдельная ирония: MCP требует стандарт, которого формально не существует. OAuth 2.1 — это до сих пор IETF‑драфт (draft‑ietf‑oauth‑v2-1), а не изданный RFC. По сути это OAuth 2.0, из которого выкинули implicit flow и password grant и сделали PKCE обязательным. Получается, протокол, который сам еще не стабилизировался, строится поверх стандарта, который тоже еще не финализирован.

Что это значит для создателей MCP

Делать аутентификацию в MCP — настоящая боль. Формат молодой, постоянно меняется, и не видно финальной версии, где остались бы только отполированные детали. Разные клиенты поддерживают разные ревизии, что не дает сидеть сразу на всех стульях. Один персонаж на Reddit утверждал, что собрал MCP‑сервер, который одинаково хорошо работает со всеми клиентами. Пруфов, естественно, не было.

Стабильное ядро, которое держится во всех свежих клиентах, всё же есть: будьте resource server’ом, отдавайте RFC 9728 discovery, валидируйте audience токена и никогда не пробрасывайте токены дальше в upstream API. Стройте под это, а остальное (способ регистрации, кто гоняет флоу) считайте конфигом под конкретного клиента. Будьте готовы поддерживать оба мира: API‑продукты «принеси свой bearer» и полнофлоу‑клиентов. И тестируйтесь против тех клиентов, которые вам реально нужны, потому что зеленый тест против актуальной спеки не значит ничего.

Из хорошего: в OAuth 2.1 можно вкладываться с уверенностью. Просто не ждите гладкой дороги и закрывайте шероховатости по мере появления.

Полезные ссылки:

• Версии спеки MCP: 2025–03-26, 2025–06-18, 2025–11-25

• Aaron Parecki, “Let’s fix OAuth in MCP”

• Christian Posta, “The updated MCP OAuth spec is a mess”

• RFC 9728 (Protected Resource Metadata, опубликован в апреле 2025)

• RFC 8707 (Resource Indicators)

• RFC 8414 (Authorization Server Metadata)

• Release candidate версии от 2026–07-28