Summary

  • draft-richer-oauth-oob-authcode-00 объединяет authorization code и сохранённый клиентом state в одно значение для ручного переноса; это индивидуальный Internet-Draft, а не принятый документ OAuth и не RFC.
  • Статическая helper page применяет HKDF, XOR и трёхбайтовый checksum. Клиент восстанавливает code и лишь затем обращается к token endpoint.
  • Совпадение checksum подтверждает только согласованную реконструкцию, но не секретность, issuer, PKCE, выдачу token, право на ресурс или бизнес-результат.

Обратный вызов заменён человеком

CLI на удалённой машине способен открыть authorization URL в браузере, но не всегда принять доступный браузеру callback. Ревизия 00 сохраняет authorization code grant и регистрирует статическую страницу как redirect_uri. AS возвращает туда code и state, страница показывает одну строку, пользователь переносит её в ожидающий клиент.

У страницы нет backend-состояния, общего секрета и роли в запросе token. AS не знает о новом формате. Механизм уменьшает вероятность перепутать две строки, не меняя цепочку полномочий.

Показ, копирование, восстановление и обмен остаются разными событиями.

Короткая проверка короткого утверждения

Code становится C. HKDF получает UTF-8 state, пустой salt и согласованный INFO, выдавая KS той же длины. Затем E = C XOR KS. Первые три байта SHA256(C) образуют T; T и E отдельно кодируются base64url без padding и соединяются в CC.

Клиент снова выводит KS из сохранённого state, получает C и сравнивает T. Несовпадение означает отказ; ввод не длиннее четырёх символов checksum отбрасывается. После этого code отправляется в token endpoint.

T не является MAC от AS. Публичная страница сформирует CC для любых значений. Совпадение не называет автора, браузерную сессию или issuer и не обещает, что code ещё действителен.

Значения раскрываются до вычисления

GET к helper содержит code и state. Origin, CDN, зеркала и cache могут увидеть их до HKDF. Проект прямо говорит: криптографические функции не добавляют защиты к базовому grant и не сохраняют code в тайне.

Кража обеих величин не исправляется CC. Клиент без сохранённого state не декодирует строку. Если JavaScript недоступен, fallback переносит полный URL и вообще не использует HKDF.

Параметры кроме code и state, включая iss, теряются. Issuer можно включить в INFO только в профиле, где клиент знает, что AS его возвращает. Значит, проверка issuer остаётся отдельной.

После вставки OAuth продолжается

RFC 6749 по-прежнему задаёт binding, redirect, срок и token request. PKCE требует соответствующий verifier. Client authentication, одноразовость и рекомендации RFC 9700 не возникают из checksum.

RFC 8628 использует другой путь: сервер выдаёт device code, клиент выполняет polling. Отказ от дополнительной поддержки и сетевых циклов полезен, но не доказывает равную безопасность и восстановление.

Minimum Initial Specification Лу Хэна ограничивает общее обещание снижением ошибок переноса. Running-Code Primacy затем проверяет, что приняли клиент, token endpoint и resource server. Одна строка не объединяет эти слои реальности.

Источники и пределы

Источники не доказывают принятие OAuth, консенсус IETF, RFC, реализацию, совместимость, внедрение, завершённый login, выданный token, атаку, успех защиты или результат ресурса. Предыдущая статья о RFC 10027 сохраняет проблему устройства-инициатора под контролем атакующего; здесь рассматривается только receipt реконструкции честного потока revision 00.