Кратко

  • draft-li-oauth-delegated-authorization-03 предлагает упорядоченную цепочку: сервер авторизации подписывает корень, а клиент может подписать для другого клиента дочерний токен только с более узкими правами. Это индивидуальный Internet-Draft с заявленным направлением Standards Track, но не RFC, не консенсус и не свидетельство внедрения.
  • Подпись дочернего элемента показывает, что его подписал ключ, связанный с непосредственным родителем. Она не доказывает доверие к корню, сохранение совокупных ограничений, отдельное согласие на делегирование или свежесть сведений об отзыве.
  • Конечный клиент предъявляет точную упорядоченную цепочку и DPoP-доказательство. Ресурсный сервер по-прежнему проверяет каждого предка, каждую связь ключей, семантическое сужение и собственную политику операции.

Система может правильно ответить на вопрос «кто подписал этот объект?» и ошибиться в более важном вопросе «кто дал подписавшему право назначить следующего участника?». Именно такой разрыв скрывается за привычной фразой «токен валиден». Дочерний JWT может быть синтаксически корректен, подписан ожидаемым ключом и привязан к свежему ключу получателя, но оставаться непригодным: родитель не имел нужного разрешения, глубина исчерпана, один из предков отозван или ресурс уже запрещает действие.

Проект делегированной авторизации OAuth превращает это различие в явную структуру. Сервер авторизации выпускает корневой Delegated Authorization Token и через cnf.jkt связывает его с ключом клиента A. Пока остаётся разрешённая глубина, A может подписать более узкий токен, связанный с ключом клиента B. B способен использовать его либо, если глубина позволяет, ещё раз уменьшить полномочие и передать его дальше.

Сервер авторизации не участвует в каждом таком шаге. Это не обход, а исходная экономия механизма: корень заранее разрешает ограниченную способность назначать следующего держателя. Цена экономии состоит в том, что ресурсный сервер при запросе обязан заново собрать весь смысл от доверенного начала до листа. Отсутствие центра в момент выпуска ребёнка не означает отсутствие центра происхождения полномочия.

Редакция 03 остаётся рабочим проектом. Заголовок говорит о намерении Standards Track, но API Datatracker сейчас не содержит значений stream и intended standard level. Запрошенные типы носителя, токена, схема аутентификации, claims и metadata ещё не являются регистрациями IANA. Текст не доказывает совместимость реализаций или производственное применение.

Доверие к корню не может исходить от самого корня

Первый элемент проверяется ключом сервера авторизации, известным через доверенную конфигурацию или аутентифицированные метаданные. Нельзя взять JWK из непроверенного корневого токена и объявить его основанием доверия: тогда злоумышленник одновременно создаст и утверждение, и якорь для его проверки.

У клиентского дочернего токена публичный JWK делегирующей стороны находится в защищённом заголовке. Проверяющий вычисляет thumbprint по RFC 7638, сопоставляет его с cnf.jkt непосредственного родителя и проверяет подпись ребёнка. Положительный результат имеет узкий смысл: обладатель ключа, разрешённого родителем, подписал следующий элемент.

Он не сообщает, каким способом A получил публичный ключ B и почему счёл его ключом нужной рабочей нагрузки, организации или арендатора. Эта ассоциация выведена за пределы проекта. Ошибочное подключение может породить идеально непрерывную криптографическую цепочку к неправильному сервису. Поэтому непрерывность ключа, идентификация участника и деловое разрешение должны оставаться разными квитанциями.

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

Сужение требует знания смысла, а не только JSON

Основное обещание проекта — монотонное ослабление. Ребёнок не может расширить эффективное полномочие всей предшествующей цепочки. Для scope это похоже на включение множеств: каждый элемент ребёнка уже должен присутствовать у родителя. Для authorization_details сравнения строк, размеров объектов или одинакового поля type недостаточно.

Каждому типу детали нужна семантическая функция подмножества. Она обязана понимать ресурсы, действия, массивы, шаблоны, значения по умолчанию и пропуски. Более короткий объект иногда шире, если отсутствие поля означает «любой». Два объекта с одним type могут касаться разных счетов или операций. Если детерминированно доказать включение невозможно, проект требует отказа.

Пропуск тоже меняет полномочие. Если ребёнок опустил scope или authorization_details, соответствующая часть разрешения исчезает и не может вернуться у внука. У audience и nbf правила иные: отсутствие нового значения не отменяет эффективного ограничения предка. Для каждого расширяемого claim необходимо заранее определить введение, наследование, отбрасывание и допустимость повторного появления.

Так проявляется институциональная граница. Универсальный валидатор не должен становиться тайным законодателем для неизвестных предметных полей. Принцип минимальной исходной спецификации из docs/heng-lu-note.md оставляет общий слой тонким и воспроизводимым. Новый смысл либо получает явный локальный профиль, либо отвергается; эвристика не превращает двусмысленность в полномочие.

Проверка должна идти по порядку от корня. Нельзя независимо валидировать набор JWT, а в конце пересечь оставшиеся поля. Пропуски, наследование и повторное введение зависят от истории. Квитанцией является вычисленный путь, а не один листовой объект.

Глубина ограничивает путь, но не радиус ущерба

Корень обязан содержать конечный max_delegation_depth. Если эффективное значение родителя равно m, явно заданное значение ребёнка должно лежать от нуля до m-1; при пропуске получается m-1. Нулевой лист может обращаться к ресурсу, но не делегировать дальше.

Это хорошая структурная граница, но не оценка риска. Глубина три способна породить тысячи потомков при широком разветвлении. Короткоживущий токен может выполнить множество операций. Узко названный scope иногда открывает высокоценный перевод или массовый экспорт. Длина одного доказательства не равна числу действующих субъектов.

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

Локальная делегация уменьшает задержку и зависимость от центрального сервиса, но убирает естественную точку наблюдения. Если после инцидента требуется найти каждого возможного держателя, необходим отдельный слой квитанций. Журнал не делает цепочку действительной и не заменяет контроль; он определяет качество восстановления.

Согласие на доступ не означает согласие на назначение

Если в grant участвует владелец ресурса, редакция 03 требует отдельно различать разрешение доступа и разрешение клиенту делегировать его дальше. «Позволить приложению читать отчёт» и «позволить приложению назначать другие приложения для чтения» — разные решения, даже если конечный scope совпадает.

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

Один связанный приватный ключ может подписывать DPoP-доказательства собственного использования и, при оставшейся глубине, новые дочерние токены. Универсальный signing oracle превращает компрометацию запросов в компрометацию назначения. Интерфейсы хранения ключа должны разделять эти две операции и их политики.

Границы ответственности трёхчастны. Сервер авторизации задаёт максимальную передаваемую оболочку. Делегирующий выбирает контрагента внутри неё и отвечает за ассоциацию ключа. Ресурсный сервер решает, допустим ли конкретный запрос сейчас. Ни одна из этих сторон не может выдать квитанцию за другую.

Порядок и точные байты входят в полномочие

Предложенный credential DA соединяет компактные JWT от корня к листу разделителем ~. Пустой элемент, неверный порядок, повреждённый токен или превышение лимита должны вызвать отказ. Значение ath в листовом DPoP хеширует точную предъявленную сериализацию. Перед вычислением нельзя декодировать, нормализовать или пересобрать токены.

Это связывание не позволяет наблюдателю удалить, добавить или переставить элементы захваченного запроса без нового листового доказательства. Но оно не делает содержание цепочки истинным. DPoP говорит, что листовой ключ одобрил запрос с этими байтами; доверие к корню, все подписи, связи cnf.jkt и ограничения проверяются отдельно.

Именно поэтому тема не повторяет существующий материал BTW об RFC 9449. DPoP регулирует sender constraint, привязку метода и URI, свежесть, replay и хеш токена. Проект использует эти механизмы на последнем ребре более крупного графа. Его собственная задача — сохранить монотонное полномочие через предков, которых выпускали клиенты.

Есть и тонкость переносимости. Дочерний токен не содержит ID родителя. Он может оказаться валидным в другой совместимой цепочке, если непосредственный предшественник связывает тот же ключ, а совокупные ограничения включают ребёнка. Отдельный ключ на токен сужает такую возможность; повторное использование ключа расширяет её. ath защищает один предъявленный запрос от изменения, но законный владелец листа способен создать новое доказательство для другой совместимой цепочки.

Отзыв завершается не ответом endpoint, а доставкой состояния

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

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

HTTP 200 не является глобальной квитанцией завершения. Такой ответ допустим и для невалидного ввода; кроме того, успешная операция лишь записывает состояние у сервера авторизации. Механизм доставки этого состояния автономным ресурсным серверам проект не задаёт. Offline-проверяющий может принимать отозванного предка до получения статуса или истечения срока.

Обещание быстрого отзыва требует коротких сроков, introspection, синхронизированных лент либо другого свежего канала. Локальный журнал должен называть источник, версию или время наблюдения статуса. Иначе невозможно согласовать «отозвано в 10:01» с «принято в 10:04».

Последнее решение остаётся у ресурса

Даже после всех криптографических и монотонных проверок ресурсный сервер применяет эффективные scope, authorization details, audience, время и предметные claims вместе с правилами арендатора, состоянием объекта, отзывом и локальным риском.

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

Положительное решение авторизации тоже не доказывает бизнес-эффект. Конфликт базы, сбой очереди, частичный внешний вызов или повтор могут изменить исход. Защита DPoP от replay не обещает exactly-once транзакцию. Квитанция commit и ключ идемпотентности находятся после OAuth.

Десять квитанций вместо одного события «успешно»

Квитанция Минимальное свидетельство Чего не доказывает
Согласие корня Grant, отдельная делегация, глубина выбор конкретного будущего ребёнка
Выпуск корня Issuer, hash, audience, права, время, cnf.jkt текущий доступ к ресурсу
Ассоциация получателя Workload, арендатор, thumbprint, канал допустимость дочерних прав
Выпуск ребёнка Ребро родителя, hash, ограничения, остаток глубины доверенный корень
Проверка цепочки Подписи, связи, времена, containment владение листом и локальный allow
Листовой proof Метод, URI, точный ath, nonce, replay валидность предков
Статус Наблюдение статуса и свежесть каждого предка доставку всем проверяющим
Локальное решение Версия политики, операция, результат commit приложения
Эффект Транзакция/идемпотентность, состояние желаемый внешний итог
Сверка Именованное наблюдение и исключения полномочие на новое действие

Разделение квитанций сохраняет причинность. Ошибка ребёнка не означает компрометацию сервера авторизации. Отказ локальной политики после валидной цепочки не является криптографической ошибкой. Неверный бизнес-результат не исправляется повторной проверкой JWT.

Итак, механизм — не просто «делегирование без центрального сервера». Центр отсутствует при выпуске ребёнка лишь потому, что заранее ограничил это отсутствие, а ресурс затем локально воспроизводит каждую границу. Дочерний токен может быть действителен. Полномочие всё равно принадлежит всей цепочке и конечной точке решения.