Vercel объявила дедлайны для вендоров: статические ключи уйдут к 2027 году

Vercel пытается сделать с API-ключами то, что Google и Let's Encrypt сделали с шифрованием трафика. Компания опросила более 1000 SaaS-вендоров и выяснила, что безопасную аутентификацию между сервисами поддерживают только 8,4%. Остальные продолжают выдавать пароли к базам и API-ключи без срока действия. Чтобы сдвинуть рынок, Vercel вводит жёсткие сроки для партнёров своего Marketplace: с 30 ноября 2026 года у вендоров, которые не поддерживают OIDC-аутентификацию от Vercel и полагаются на долгоживущие секреты, в листинге появится пометка «Not secure». С января 2027 года такие провайдеры будут удалены из каталога.

Почему статический ключ стал проблемой именно сейчас

Долгоживущий статический секрет — это API-ключ или пароль, который приложение использует снова и снова, часто без срока годности. Такой ключ может утечь в репозиторий или чат, его могут украсть через скомпрометированную зависимость. Теперь добавился ещё один путь: prompt injection, при которой агента заставляют выдать собственные учётные данные. Агентам при этом дают доступ к системам и данным через ключи, права которых нередко шире, чем нужно для конкретной задачи.

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

Что предлагает Vercel вместо ключей

Альтернатива давно известна: OIDC. Доверенный издатель выдаёт подписанный краткоживущий токен, идентифицирующий приложение, а принимающий сервис проверяет его и решает, какой доступ дать. Украденный токен перестаёт работать после истечения срока. Новые токены приложение получает программно, так что раздавать и вручную менять постоянный ключ не нужно.

OIDC-федерация на Vercel доступна с 2024 года: приложения обменивают токены платформы на временные учётные данные AWS, Google Cloud и Azure по настроенным политикам доверия для проекта и окружения. Теперь компания расширяет подход на собственные сервисы Blob, AI Gateway и Sandbox, а также на Vercel API и CLI, чтобы убрать долгоживущие токены из деплой-процессов.

Набор новых инструментов:

• OIDC UI — реестр компонентов shadcn/ui с конфигуратором trust-policy и серверным верификатором токенов. Есть готовые формы для Vercel, GitHub, GitLab, Google, Bitbucket, AWS, Azure и произвольных OIDC-издателей.
• Vercel Connect — приложения и агенты запрашивают токены провайдеров в рантайме по идентичности деплоймента. В коде это один вызов getToken с указанием пользователя и scopes, например для доступа к Linear.
• Custom audience — токен привязывается к единственному сервису-получателю.
• Пример с Azure — ClientAssertionCredential обменивает токен Vercel на доступ к Cosmos DB без ключа базы.

Задержки и стимулы

Vercel признаёт, что у статического ключа есть преимущество: он уже лежит в переменной окружения, и сетевой запрос не нужен. Получение и обмен токенов добавляют задержку. Поэтому функции Vercel получают токен платформы в заголовке запроса, и SDK читает его без дополнительного вызова. Платформа переиспользует неистёкшие токены, а Vercel Connect кэширует токены провайдеров в процессе и обновляет их ближе к концу срока. Сетевые вызовы остаются только для custom audience и обмена на токены провайдеров.

Кроме удобства и скорости, Vercel называет третью преграду: у вендоров мало стимулов заниматься этим. Здесь и нужен пример Chrome, который сначала пометил HTTP как «Not secure», а затем назначил дедлайны. Vercel собирается пройти тот же путь и обещает те же требования к собственному API и нативным интеграциям. Кроме того, компания хочет, чтобы интеграции из Marketplace настраивали безопасную аутентификацию автоматически при подключении сервиса, без отдельного шага.

Что делать разработчикам и провайдерам

Если вы строите продукт для клиентов Vercel, до 30 ноября нужно решить, принимаете ли вы OIDC-токены напрямую или обмениваете их на временные учётные данные. Компоненты OIDC UI позволяют не писать с нуля ни форму настройки доверия, ни проверку токенов. Если вы просто используете сервисы через Marketplace, имеет смысл заранее проверить, у каких подключённых провайдеров вы храните постоянные ключи в переменных окружения, и составить план их замены. Для агентских приложений логичная отправная точка — Vercel Connect: токен под конкретного пользователя и конкретные scopes ограничивает ущерб при prompt injection. Старые ключи после миграции стоит отозвать, а не просто перестать использовать.