Payload CMS готовит OAuth для MCP: ИИ-агенты смогут подключаться без ручных API-ключей

24 октября 2026 г.•Александр Андреев

В Payload CMS разрабатывают встроенную OAuth-авторизацию для MCP. Она должна упростить подключение Claude, Codex и других MCP-клиентов к данным и инструментам Payload: вместо ручного создания API-ключей и отдельной инфраструктуры авторизации — вход в админку и одно подтверждение доступа.

Изменения оформлены как pull request в репозитории Payload: https://github.com/payloadcms/payload/pull/19036

Как это будет работать

Сегодня у удалённого подключения к MCP через Payload нет штатного сценария авторизации: разработчик либо вручную выдаёт клиенту API-ключ, либо поднимает отдельный OAuth-сервер ради одного эндпоинта. Новая реализация добавляет OAuth-сервер непосредственно в официальный плагин @payloadcms/plugin-mcp — по умолчанию OAuth-сервером становится сам Payload.

Сценарий для пользователя выглядит примерно так: ИИ-клиент обращается к эндпоинту /api/mcp, Payload предлагает войти под существующей учётной записью, пользователь подтверждает доступ для приложения. После этого клиент получает токен и может обращаться к разрешённым инструментам MCP от имени этого пользователя.

В конфигурации плагина это одна настройка, причём встроенный режим — значение по умолчанию:

mcpPlugin({
  oauth: { type: 'builtin' }, // значение по умолчанию
  // oauth: { type: 'external', authorizationServers: ['https://auth.example.com'] },
  // oauth: false,
})

Альтернативы предусмотрены: можно указать внешний сервер авторизации — например, если в команде уже есть свой SSO — или отключить механизм совсем. Запросы к MCP без учётных данных при этом получают OAuth challenge вместо анонимного выполнения, так что «тихого» доступа без авторизации не останется.

Отдельно плагин начнёт экспортировать функции issueToken и refreshToken: они позволят приложениям выдавать на MCP собственные токены, если встроенной схемы проекту мало.

Заодно — refresh-токены для всей auth-системы

Второй pull request добавляет в Payload refresh-токены: https://github.com/payloadcms/payload/pull/19040

Это изменение касается не только MCP: опция auth.refreshTokens появляется в auth-коллекциях вообще. При входе вместе с обычным токеном возвращается refreshToken, который операция обновления обменивает на новый токен и новый refresh-токен — в том числе после истечения срока исходного токена.

{
  slug: 'users',
  auth: {
    refreshTokens: true, // или { expiration: 60 * 60 * 24 * 7 }, по умолчанию 30 дней
  },
}

Клиент обновляет токен запросом к эндпоинту вида /api/users/refresh-token:

await fetch('/api/users/refresh-token', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ refreshToken }),
})

Механика безопасности описана в PR так: каждый refresh-токен срабатывает один раз, при повторном использовании уже заменённого токена Payload завершает сессию пользователя. Для плагинов экспортируются функции createAuthToken и redeemRefreshToken.

Мотивация простая: приложения, которые работают не постоянно — мобильные клиенты, CLI и как раз MCP-клиенты, — не успевают обновить токен до истечения. Сегодня им остаётся либо снова проводить пользователя через логин, либо искусственно поднимать tokenExpiration. Refresh-токены позволяют держать сессию долго, а сам токен — короткоживущим.

Почему это важно именно для MCP

Для Payload эта пара функций особенно полезна в сочетании с Access Control. Подключённому агенту не обязательно выдавать универсальный API-ключ с широкими правами: взаимодействие привязывается к конкретному пользователю CMS, и срабатывают его обычные ограничения доступа — по коллекциям, полям и операциям.

С токенами и refresh-механикой решается и проблема долгих сессий: агент может оставаться подключённым неделями без ручной повторной авторизации, а при компрометации сессию можно отозвать.

Практическая выгода для типичного проекта — убрать целый слой ручной работы: не создавать и не ротировать API-ключи для каждого ИИ-клиента и не разворачивать отдельный сервер авторизации. Авторы Payload называют и более прикладной аргумент: некоторые клиенты, например кастомные коннекторы claude.ai, поддерживают только OAuth — с встроенным сервером они подключаются к Payload без дополнительной инфраструктуры.

Насколько этому доверять

Пока это план, а не релиз. Оба pull request открыты 23 октября 2026 года, OAuth-вариант находится в статусе draft — реализация может измениться до включения в Payload. Автор обоих изменений — AlessioGr, указанный как участник команды Payload, так что направление официальное.

В свежих релизах функции ещё нет: актуальная стабильная версия плагина @payloadcms/plugin-mcp — 3.92.0 от 22 октября, и встроенного OAuth-сервера в ней нет. Когда изменения доедут до релиза и в какой версии — в PR не указано. Мы бы проверили конфигурацию oauth и поведение refresh-токенов по документации конкретного релиза, когда он выйдет: имена опций в draft-PR регулярно переезжают.

Если подключение ИИ-агентов к Payload в проекте уже востребовано, сейчас это по-прежнему API-ключи плюс Access Control — рабочая, но более громоздкая схема. А OAuth-сервер и refresh-токены выглядят как недостающая деталь, после которой MCP из Payload станет подключаться в пару кликов.

Источники

PR #19036 — встроенный OAuth-сервер для MCP: https://github.com/payloadcms/payload/pull/19036

PR #19040 — refresh-токены: https://github.com/payloadcms/payload/pull/19040

Обсуждение #16745, с которого началась работа над OAuth для MCP: https://github.com/payloadcms/payload/discussions/16745

Плагин @payloadcms/plugin-mcp в npm: https://www.npmjs.com/package/@payloadcms/plugin-mcp

Назад в блог