WorkOS представил auth.md-открытый OAuth‑протокол для автоматической регистрации программных агентов

WorkOS выпустил спецификацию auth.md-простой Markdown‑файл, который сервис публикует на своём домене (обычно по адресу https: //service.com/auth.md) и который одновременно служит документацией для разработчиков и машинно‑читаемым артефактом для автоматической регистрации программных агентов. Это упрощает доверительную интеграцию агентов с сервисами и стандартизирует обмен сведениями о поддерживаемых потоках регистрации и областях доступа. Для автоматического обнаружения auth.md предлагает двухэтапный процесс. Сначала защищённый ресурс в /.well-known/oauth — protected — resource указывает на Authorization Server; затем метаданные сервера в /.well-known/oauth — authorization — server содержат блок agent_auth с полями register_uri, claim_uri, revocation_uri и identity_types_supported. Для бутстрэппинга агентов может использоваться форма вида Bearer resource_metadata="...", содержащая нужные сведения для старта.

Спецификация описывает два основных регистрационных потока. В Agent verified flow агент получает удостоверение ID‑JAG от доверенного провайдера идентификации (примеры провайдеров, указанные в документе: OpenAI, Anthropic, Cursor или иной доверенный провайдер) и отправляет это удостоверение POST‑запросом на /agent/auth. Сервис декодирует JAG, извлекает kid и alg, находит издателя в списке доверенных провайдеров, загружает JWKS провайдера, проверяет подпись и валидирует стандартные claims (aud, exp, iat, jti, client_id). При необходимости провайдер может отозвать делегацию, отправив logout‑token на revocation_uri.

User claimed flow делает ставку на одноразовый код (OTP) и не требует участия внешнего провайдера идентификации. Агент инициирует процесс регистрации, после чего пользователь подтверждает владение учётной записью через цепочку подтверждений: сначала /agent/auth/claim для отправки письма с кодом, затем /agent/auth/claim/complete для ввода кода. либо с указанием email при регистрации, когда креденшелы не выдаются до успешного подтверждения.

Спецификация также фиксирует практики безопасности. Токены доступа, выданные по результатам верификации через ID‑JAG, не должны сопровождаться refresh‑токеном — продление прав требует выдачи нового ID‑JAG. Ключи и делегации обязаны быть аудитируемыми и иметь механизм отзыва через revocation_uri. WorkOS отмечает, что схему можно соотнести с JIT‑провиженом пользователей, реализуемым через OIDC или SAML, но формат издателя и аттестаций в auth.md отличается.