Кратко

  • Редакция 01 draft-zehavi-oauth-authz-req-del-chain объявлена 10 сентября 2026 года как индивидуальный Internet-Draft; это не документ, принятый рабочей группой OAuth, и не RFC.
  • Отделённые подписи JWS, хеши предыдущих узлов, позиции и непрерывность аудитории защищают целостность пути брокеров, видимого вышестоящему серверу авторизации.
  • Удаление конца или середины должно нарушить проверку. Но брокер способен создать новую правильную цепочку, поставив себя в chain[0].
  • Допустимость первого видимого издателя для данного клиента, ресурса и развёртывания поэтому определяет локальная политика.

Безупречная проверка не восстанавливает предысторию

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

Проект OAuth Authorization Request Delegation Chain предлагает передавать путь в объекте RAR authorization_details. В каждом JSON-узле указаны удостоверяющая сторона, аудитория, позиция и клиент, о котором сделано утверждение. Отделённая JWS подписывает детерминированное представление узла, а p_hash связывает его с предыдущим подписанным событием.

Получатель идёт от последнего узла назад. Он проверяет, что последний aud указывает на него, а iss связан с OAuth-клиентом, который действительно прошёл аутентификацию и представил запрос. Затем сверяются ключи, подписи, номера, пространства имён, хеши и переход от аудитории одного узла к издателю следующего.

Успех означает целостность предъявленного пути. Он не отвечает, существовал ли участок до первой предъявленной записи.

Два разрыва видны, третий становится новым началом

Редакция 01 разбирает три варианта усечения. Если удалить хвост, цепочка закончится на аудитории, не совпадающей с сервером-получателем. Если убрать средний узел, перестанут сходиться p_hash преемника и отношения соседних издателей и аудиторий.

С головой цепочки иначе. Брокер может отбросить прежний контекст и создать новую последовательность, где он стоит под номером ноль, а предыдущий хеш равен null. Все дальнейшие подписи могут быть подлинными. Документ называет это повторным происхождением — re-origination — и признаёт, что проверка не доказывает отсутствие контекста перед chain[0].

Это не сообщение об атаке, а собственная граница проекта. Хеш-цепочка обеспечивает непрерывность от заявленного начала, но не становится внешним свидетелем полноты этого начала.

Поэтому сервер должен применить локальное правило: разрешено ли этому издателю быть первым для такого клиента, ресурса и контекста? Верная подпись также не наделяет издателя полномочиями брокера. Поле client_roles может содержать oauth_broker, однако самозаявленная роль не служит доказательством доверия. Обычная аутентификация непосредственного OAuth-клиента остаётся обязательной.

Разрешение убрать цепочку действует только вперёд

Новая редакция добавляет обнаружение поддержки через метаданные RFC 8414. Если следующий сервер не понимает профиль, брокер не вправе молча удалить уже полученную цепочку.

Он должен отказать, сохранить контекст другим доверенным способом либо продолжить без цепочки только при разрешении локальной политики и подписанных узлов. Необязательное omit_chain принимает allowed или forbidden; отсутствие поля означает запрет. Для удаления требуется согласие каждого проверенного узла.

Так потеря уже известного свидетельства становится явной. Но правило ничего не говорит о контексте, отброшенном до создания первого узла. Допуск будущего понижения и доверие к заново объявленному началу — разные решения.

Редакция также просит IANA зарегистрировать client_roles. Пока это предложение индивидуального проекта, а не состоявшаяся регистрация, консенсус IETF, принятие рабочей группой, реализация, внедрение или инцидент.

Источники