Кратко

  • 28 сентября Justin Richer представил индивидуальный Internet-Draft: код авторизации OAuth можно перенести из браузера в удалённый клиент одним копируемым значением.
  • Удобство передачи не является новой защитой. Вспомогательная страница получает code и state, а клиент должен проверить связь с ожидавшим запросом и сервером авторизации.

Командная строка на удалённой машине способна начать авторизацию, но не всегда способна предоставить адрес возврата, доступный браузеру пользователя. draft-richer-oauth-oob-authcode-00 предлагает зарегистрировать в качестве такого адреса вспомогательную страницу. Пользователь получает на ней строку и вставляет её в ожидающий терминал. Это индивидуальный проект от 28 сентября 2026 года с намерением опубликовать информационный документ. Datatracker показывает I-D Exists, а не принятие рабочей группой, одобрение IETF или статус RFC.

Сервер авторизации отправляет обычный ответ на зарегистрированный URI. Страница берёт code и state, применяет HKDF с материалом из state, XOR и короткую контрольную сумму, затем показывает одно значение. Клиент сохранил исходный state и потому может восстановить код, после чего обращается к обычной конечной точке токенов. Серверу не предлагается новый тип гранта; ему требуется зарегистрировать адрес страницы возврата.

Видимая экономия шагов не сокращает число получателей. Авторы проекта прямо пишут, что комбинация не повышает безопасность по сравнению с базовым потоком кода авторизации. Параметры code и state приходят на страницу в URL запроса GET. Даже статическую страницу обслуживают хостинг, CDN, зеркала и кеши; журналы доступа тоже могут сохранить URL. Отсутствие серверной сессии у страницы не делает доставку к ней невидимой.

Строка для вставки также не удостоверяет сервер авторизации. Алгоритм может исполнить любой участник с произвольными исходными значениями. Важно, чтобы клиент сопоставил результат со своим незавершённым запросом, сохранённым state, ожидаемым сервером и нужной конечной точкой токенов. Клиент без сохранённого состояния этот вариант использовать не может. На случай отказа JavaScript проект упоминает копирование полного URL; тогда исходные параметры передаются напрямую, а не в комбинированном формате.

Особенно внимательно следует читать состав ответа. Основное значение переносит code и state, но не отдельный параметр iss и не другие поля. Раздел 3.4 допускает использование iss в поле INFO HKDF, если клиент знает, что сервер его отправляет. RFC 9207 уже описывает идентификацию издателя как меру против путаницы между несколькими серверами авторизации. Из отсутствия отдельного поля нельзя автоматически вывести уязвимость всех реализаций. Однако многосерверному клиенту нужно сохранить прежний способ привязки ответа к издателю.

Авторизация устройств по RFC 8628 остаётся иной возможностью: она требует поддержки сервера и периодических запросов. Новый проект её не отменяет и не предписывает повсеместный переход. Его выбор — использовать поток кода для удалённого клиента, взамен принимая страницу-посредника и человеческую передачу как части рабочей схемы.

Источники