Кратко

  • Редакция 11 draft-ietf-oauth-attestation-based-client-auth вышла 3 сентября 2026 года. 8 сентября рабочая группа OAuth открыла Last Call до 22 сентября.
  • Серверные challenge необязательны. Срок и возможность использовать одно значение в одном или нескольких Client Attestation PoP JWT определяет только локальная политика сервера. Клиент обязан брать последнее значение, но вправе повторить его.
  • Сервер с правилом single use отклоняет вторую попытку кодом use_attestation_challenge, выдаёт новое значение и допускает одну повторную попытку, не бесконечный цикл. Совмещённый режим DPoP использует nonce из RFC 9449.
  • Новые метаданные описывают методы и алгоритмы, но не правило потребления. Daniel Kade предлагает объявлять freshness policy в профиле внедрения; это редакционное предложение, а не требование IETF.

Last Call проверяет готовность текста

Объявление рабочей группы OAuth просит до 22 сентября выразить поддержку или объяснить возражения. Datatracker показывает редакцию 11 как действующий документ группы в состоянии In WG Last Call. Это существенная стадия формирования согласия, но ещё не RFC, не итоговое одобрение и не консенсус всего IETF.

Механизм аутентифицирует отдельный экземпляр клиентской программы. Client Attester выпускает подписанный Client Attestation JWT и связывает своё утверждение с открытым ключом установки. При обращении к серверу авторизации или защищённому ресурсу экземпляр отдельно доказывает владение соответствующим закрытым ключом. Аттестация отвечает за свидетельство, PoP — за текущий контроль ключа.

В обычном режиме доказательством служит Client Attestation PoP JWT. В нём есть время создания и уникальный jti. Сервер может добавить собственный непрозрачный challenge для проверки свежести. Значение приходит с ошибкой, в одном из предыдущих ответов либо с опубликованного challenge endpoint. После получения клиент обязан использовать самый новый вариант.

Редакция 11 не устанавливает общий срок жизни и не требует одноразовости. Можно ли поместить тот же challenge в несколько PoP JWT, решает исключительно локальная политика сервера авторизации или ресурса. Клиенту разрешено повторное использование; серверу с одноразовым правилом — отказ при второй попытке.

Оба решения разумны в разных условиях. Одно значение на одну операцию сужает границу, но требует состояния и координации параллельных запросов. Короткий период повторного использования удобнее распределённой системе, если jti или другая проверка ловит повтор именно того же доказательства. Проблему создаёт не выбор, а невозможность узнать его по непрозрачному значению.

Ошибка выполняет роль запроса к политике

После расхождения процедура определена чётко. Сервер авторизации возвращает HTTP 400 и use_attestation_challenge; защищённый ресурс — HTTP 401 в ответе аутентификации. В обоих случаях обязателен новый заголовок OAuth-Client-Attestation-Challenge. Клиент создаёт новый PoP JWT и должен попробовать ещё один раз, но не повторять бесконечно.

Ограничение останавливает цикл, однако не устраняет первый отказ. Приложение может заранее получить значение и раздать его нескольким процессам для параллельных token-запросов. Сервер с повторным использованием принимает разные доказательства с новыми jti. При single use одна операция расходует значение, а остальные внезапно становятся неверными. Решение клиента разделить challenge соответствовало проекту; необходимость очереди открылась только после ошибки.

Раздел безопасности показывает, почему отметка «challenge включён» мало что говорит. Сервер может хранить увиденные jti в скользящем окне и находить повтор того же PoP JWT. Он может также сохранять значения, выданные endpoint, и получить более сильное обнаружение replay по собственному случайному значению. Цена — таблица состояния и, возможно, дополнительный сетевой обмен.

Допустим и самодостаточный challenge без списка уже увиденных значений. Такой вариант хорошо масштабируется, но гарантирует лишь свежесть и не препятствует replay внутри разрешённого окна. Ещё один вариант связывает конкретное значение с сессией Client Instance. Одинаковое поле поэтому может означать разные расходы, свойства конкурентности и уровень защиты.

Поддержка challenge остаётся необязательной ради простого обязательного минимума. jti обязателен и служит базовым запасным механизмом; серверу также следует проверять допустимое временное окно. Наличие challenge само по себе не доказывает одноразовость или хранение replay-состояния.

У DPoP остаётся собственный канал свежести

В совмещённом режиме одно доказательство DPoP по RFC 9449 подтверждает владение ключом экземпляра и ограничивает access token отправителем. В редакции 11 прямо сказано, что здесь применяется исключительно nonce-механизм DPoP.

Если ожидаемого nonce нет, сервер отвечает use_dpop_nonce, а новое значение помещает в DPoP-Nonce. Это не обычный путь use_attestation_challenge. Challenge endpoint может заранее передать DPoP nonce и сэкономить неудачный обмен, но общий адрес доставки не делает две семантики взаимозаменяемыми.

Официальное сравнение редакций 10 и 11 отдельно отмечает исключительное использование DPoP nonce, его выдачу через endpoint и уточнение необязательных challenge с ошибками. Если SDK смешает два кэша, он сотрёт границу, которую новая редакция только что закрепила.

Метаданные заканчиваются перед правилом потребления

Редакция 11 добавляет клиентские метаданные на основе общей модели RFC 7591. Обе стороны могут объявить поддерживаемые алгоритмы подписи и методы PoP, включая attestation_pop_jwt и dpop_combined. Сервер может опубликовать URL challenge_endpoint. Несколько несовместимостей становятся видны до создания подписи.

Но клиент не узнает правило, которое сильнее всего меняет планирование. Метаданные не говорят, обязателен ли challenge, к какому классу относится его срок, расходует ли его первый успех, хранит ли сервер увиденные значения, даёт ли самодостаточная форма только свежесть и для какого режима действует правило. Нет и версии политики, с которой оператор мог бы связать всплеск отказов второго использования.

Точные секунды или устройство хранилища публиковать не нужно. Параметры вправе меняться с нагрузкой и риском. Достаточно наблюдаемых классов: single-use, reusable или session-bound; witnessed-state или freshness-only. Они помогают клиенту выбрать очередь и не позволяют аудитору приписать системе лишнюю гарантию.

Daniel Kade предлагает небольшой объект freshness-policy в профиле внедрения. Для каждого PoP-режима он сообщал бы, поддерживается или требуется серверная свежесть, где выдаётся значение, каков класс срока и потребления, какова replay-позиция, сколько автоматических повторов разрешено и какова эпоха политики. Подписанная квитанция обнаружения могла бы связать декларацию с прочитанной версией метаданных.

Такого требования в редакции 11 нет, и рабочая группа его не согласовала. Сам проект разрешает экосистемам профилировать механизм. Именно там идею можно проверить, не меняя базовый протокол и не создавая альтернативу nonce из RFC 9449.

Источники