TL;DR
Документы метаданных идентификатора клиента Okta (CIMD) заменяют ручную регистрацию OAuth-клиентов за счет использования HTTPS-URL в качестве client_id. Okta динамически получает, проверяет и кэширует метаданные клиента по запросу с этого URL, что позволяет ИИ-агентам безопасно проходить аутентификацию в тысячах клиентских организаций без статических учетных данных или предварительных препятствий для регистрации.
Агентный ИИ меняет представление о том, что означает «клиент» в вашей архитектуре идентификации. Несколько лет назад клиенты, обращавшиеся к вашим API, в основном представляли собой горстку собственных приложений и несколько доверенных сторонних интеграций, причем каждое из них один раз настраивалось человеком через консоль администратора. Сегодня эта экосистема выглядит совсем иначе: ИИ-агенты, серверы протокола контекста моделей (MCP) и автономные рабочие нагрузки создаются, клонируются и выводятся из эксплуатации другим программным обеспечением — часто поставщиками, которых вы напрямую не контролируете, — с тем темпом, с которым не способна справиться ни одна консоль администратора.
Для решения этой проблемы компания Okta внедрила две функции, которые теперь доступны всем клиентам на базе Okta Identity Engine:
- Поддержка документов метаданных идентификатора клиента (CIMD) для OAuth 2.0: универсальная функция, которая позволяет любому клиенту OAuth 2.0 (независимо от того, является ли он агентом) выполнять аутентификацию путем публикации информации о себе по URL-адресу вместо прохождения этапа ручной регистрации для каждой организации, с которой ему нужно взаимодействовать.
- Регистрация на основе CIMD для ИИ-агентов: применение этой же модели конкретно к тому, как ИИ-агенты получают свои идентификационные данные в Okta.
Вот что это значит, почему это важно и почему это не влечет за собой ущерба для безопасности.
Почему традиционная регистрация OAuth не работает для агентного ИИ
Традиционная регистрация клиентов OAuth предполагает относительно небольшую и относительно статичную совокупность клиентов. Администратор либо вручную создает OAuth-клиент в консоли (имя, URI перенаправления, типы предоставления доступа, генерация секретного ключа), либо клиент использует динамическую регистрацию клиентов (RFC 7591), чтобы запросить у сервера авторизации программное создание клиента. В любом случае клиент получает идентификационные данные, выданные сервером авторизации (client_id и, как правило, секрет), которые хранятся в базе данных этого сервера.
Эта модель отлично работает при регистрации небольшого числа внутренних приложений. Она быстро становится неэффективной, когда:
- Платформу агента или сервер MCP необходимо использовать во множестве клиентских организаций, каждая из которых требует собственного этапа регистрации;
- Экземпляры агентов создаются и уничтожаются программно быстрее, чем за ними успевает следить администратор-человек;
- Сущность, «владеющая» идентификационными данными агента, вовсе не является администратором организации — это поставщик агента, который уже где-то поддерживает метаданные о своем программном обеспечении.
Кратко говоря: сам этап регистрации (а не последовавшая за ним аутентификация) стал бутылочным горлышком для рабочих нагрузок и идентификации агентов в больших масштабах.
Как работает CIMD: динамическое разрешение метаданных
CIMD использует иной подход, заимствованный из зарождающейся модели в экосистеме OAuth, и применяется к любому клиенту OAuth 2.0 в Okta, а не только к ИИ-агентам. Вместо предварительной отправки метаданных на сервер авторизации CIMD меняет архитектуру на модель «опубликовать один раз, запросить по требованию»:
- URL в качестве идентификатора клиента: вместо регистрации клиента и получения в ответ непрозрачного client_id в качестве client_id используется HTTPS-URL, который уже контролируется клиентом (или его поставщиком).
- Динамическое извлечение метаданных: при поступлении запроса на аутентификацию Okta разыменовывает этот URL для получения JSON-документа с описанием клиента (те же метаданные, которые вы обычно отправляете при динамической регистрации клиентов: URI перенаправления, поддерживаемые типы предоставления прав, набор ключей JSON Web Key для проверки подписи, метод аутентификации эндпоинта токенов и т. д.).
- Кэширование и выпуск токенов: когда поступает запрос с использованием этого URL в качестве client_id, Okta получает, проверяет и кэширует документ по запросу, а затем использует его для определения личности клиента — никаких предварительных вызовов регистрации не требуется.
Для поставщика агентов, обслуживающего тысячи клиентских организаций, это разница между тысячами вызовов регистрации и одним размещенным JSON-файлом.
Безопасен ли CIMD? Как Okta обеспечивает соблюдение средств контроля Zero Trust
Здесь стоит быть точным, поскольку фраза «клиент описывает себя сам» может звучать так, будто она устраняет средство обеспечения безопасности, а не переносит его. Это не так. Okta не считает произвольный URL допустимым client_id просто потому, что он выглядит правильно. Okta обеспечивает административный контроль на каждом уровне:
- Предварительная проверка белого списка администраторов: перед извлечением CIMD-URL компания Okta сверяет его с правилом белого списка, явно настроенным администратором организации.
- Точное сопоставление URL: документы должны сами заявлять точный URL (администратор указывает точный CIMD-URL, которому доверяет эта организация). Если совпадающего правила нет, Okta никогда не отправляет запрос. Именно администратор, а не сеть Интернет, решает, каким идентификаторам на базе CIMD доверяет эта организация.
- Подтверждение владения (DPoP и mTLS): администраторы могут пойти дальше простого белого списка. Okta поддерживает добавление дополнительных требований к записи CIMD, поэтому для признания полученного документа действительным может потребоваться соблюдение определенных условий политики — например, декларация поддержки определенного механизма подтверждения владения. При этом сам документ может заявлять, что любые токены, выданные этому клиенту, должны быть привязаны к демонстрации подтверждения владения (DPoP) или взаимному TLS (mTLS), что означает, что требование подтверждения владения сопровождает самозаявленную идентичность, а не настраивается отдельно по внеполосным каналам.
В результате получается модель, в которой удобство заключается в отсутствии необходимости предварительно регистрировать каждого клиента, а управление остается ровно там, где оно всегда было: у организации, которая решает, чему она доверяет.
Здесь стоит внести ясность в отношении области применения: поддержка CIMD не привязана исключительно к агентам. Любое пользовательское приложение OpenID Connect (OIDC) в Okta сегодня может быть настроено как CIMD-клиент. Как только администратор разрешает его URL, это приложение проходит аутентификацию и получает токены через те же потоки OAuth 2.0, которые используются всеми остальными клиентами, вообще без участия ИИ-агентов. Регистрация ИИ-агентов, о которой пойдет речь далее, является просто новейшей специализированной реализацией той же базовой возможности.
Защита нового поколения ИИ-агентов
Поддержка CIMD для OAuth 2.0 является фундаментом. Регистрация на основе CIMD для ИИ-агентов делает эту возможность непосредственно применимой к модели идентификации агентов в Okta.
При регистрации ИИ-агента в Okta теперь можно подтвердить идентичность этого агента с помощью CIMD-URL вместо того, чтобы запрашивать у Okta создание традиционного OAuth-клиента. На практике это поддерживает два сценария: регистрация совершенно новой идентичности агента на основе CIMD-документа или перенаправление новой регистрации агента на существующее приложение на базе CIMD для перенятия этой опубликованной идентичности.
Это естественным образом согласуется с тем, как уже работают платформы агентов и серверы MCP. Эти платформы обычно уже публикуют метаданные с описанием своего ПО — это заложено в них для обеспечения обнаруживаемости и взаимодействия. CIMD позволяет Okta использовать эти существующие метаданные напрямую в качестве основы для доверенной идентичности, избавляя поставщика от необходимости дополнительно выполнять отдельный процесс регистрации для каждой клиентской организации, желающей использовать их агента.
Устранение статических клиентских секретов
CIMD обходит менее заметную проблему традиционной регистрации — клиентские секреты. OAuth-клиент, созданный в Okta, обычно поставляется с секретом, который необходимо подготовить, безопасно хранить и периодически ротировать — это еще одна долгоживущая учетная запись для управления каждым агентом. Идентификатору агента на базе CIMD он не нужен; аутентификация опирается на ключи и метаданные, опубликованные в самом документе, в сочетании с механизмами подтверждения владения, такими как взаимный TLS (mTLS) или подписанные утверждения.
Отзыв идентификаторов и контроль доступа
И поскольку привязка между идентификатором CIMD и агентом является взаимно однозначной, нет никакой двусмысленности в том, какого именно агента представляет данный идентификатор — попытки повторно использовать идентификатор, который уже привязан к другому агенту, сразу же отклоняются. Отключение агента со стороны Okta немедленно аннулирует его токены, независимо от того, что все еще говорит размещенный извне документ с метаданными. Разрешение идентификаторов и контроль их жизненного цикла представляют собой два раздельных уровня, и оба остаются под контролем организации.
В более широком смысле это меняет распределение зон ответственности в отношениях аутентификации. Разработчики агентов сохраняют контроль над собственными ключами и графиком их ротации на собственной инфраструктуре — больше не нужно отправлять заявку в ИТ-отдел каждый раз, когда требуется обновить учетные данные. Администраторы, в свою очередь, освобождаются от управления ключами для каждой учетной записи и переходят к управлению доверием: они определяют, какие URL-адреса агентов следует внести в белый список, и сохраняют возможность в реальном времени заблокировать доступ агента при необходимости. Именно этот сдвиг делает такой подход практической основой для более крупных архитектур агентов — включая собственные решения Okta Agent Gateway и интеграции с такими инструментами, как Claude Code от Anthropic и Salesforce Agentforce, — где количество различных идентификаторов агентов, которым организации необходимо доверять, может значительно превысить то, на что изначально была рассчитана ручная регистрация.
Надежная структура для идентификации агентов
Вполне естественно относиться с долей скептицизма к любой модели, в которой сервер авторизации запрашивает и доверяет документу, размещенному в другом месте. Архитектура здесь напрямую учитывает очевидные сценарии сбоев:
- Белый список перед запросом: Okta проверяет соответствие заданным администратором критериям перед совершением любого исходящего запроса — незарегистрированный URL-адрес изначально даже не обрабатывается.
- Документ должен соответствовать URL-адресу: метаданные, полученные по конкретному URL-адресу, должны указывать этот же URL-адрес в качестве собственного client_id. Документ не может заявлять, что представляет другого клиента, отличного от того, для которого он был запрошен.
- Только HTTPS, без обходных путей: URL-адреса CIMD проверяются структурно — никаких встроенных учетных данных, фрагментов или манипуляций с путями, которые могли бы запутать процесс определения того, чей именно идентификатор разрешается.
- Ограниченное кэширование: документы кэшируются с ограниченным временем жизни, поэтому существует жесткий предел того, как часто и как быстро можно обращаться к любой отдельной конечной точке через Okta.
- Идентификация — это не авторизация: разрешение CIMD-документа сообщает Okta, за кого себя выдает клиент. Это ничего не говорит о том, что этому клиенту разрешено делать. Администраторам по-прежнему необходимо явно подключать агента к конкретным ресурсам и API, к которым ему разрешен доступ — корректно идентифицированный агент не получает неявного доступа ни к чему.
Проще говоря: самозаявленная идентификация — это все равно идентификация, которой Okta решает доверять на условиях, заданных организацией, с теми же гарантиями подтверждения владения и контроля доступа, что и у любого другого OAuth-клиента.
Начните работу с CIMD уже сегодня
Поддержка CIMD для OAuth 2.0 и регистрация на основе CIMD для ИИ-агентов теперь доступны для всех организаций клиентов на базе Okta Identity Engine. Узнайте больше о CIMD и о том, как эта функция работает в вашей организации.
Поскольку агентный искусственный интеллект продолжает менять представление о том, что такое «клиент» в вашей среде, это лишь один из элементов масштабных усилий Okta, направленных на то, чтобы этот переход не происходил в ущерб пониманию и точному контролю того, кто именно подключается к вашим системам.
Эти материалы предназначены исключительно для общего ознакомления и не являются юридическими, конфиденциальными, охранными, нормативными или деловыми рекомендациями. Любые функции или услуги, находящиеся в разработке или доступные в режиме бета-тестирования, раннего доступа или аналогичном статусе ограниченного доступа, могут не разрабатываться, не выпускаться или не предоставляться в общем доступе, либо могут иметь другие функции, возможности, технологии, конфигурации и/или документацию на момент выпуска (если таковой состоится). © 2026 Okta, Inc. и/или ее аффилированные лица.
