Кратко

  • draft-ietf-oauth-rar-metadata-remediation-00 позволяет серверу ресурса ответить на корректный, но недостаточно авторизованный OAuth-запрос исполнимыми объектами Rich Authorization Requests, которые клиент может использовать в новом процессе авторизации.
  • Сервер ресурса не выдаёт полномочия. Он формулирует, что считает достаточным; сервер авторизации и владелец ресурса проверяют запрос, применяют политику, дают согласие, сужают его или отказывают, после чего сервер ресурса снова применяет контроль.
  • Daniel Kade предлагает журнал изменения полномочий, связывающий неудачную операцию, исходные полномочия, предложенные детали, происхождение схемы, результат согласия, фактическую выдачу и итоговое действие над ресурсом. Это рекомендация по управлению, а не требование проекта.

Отказ, в котором уже содержится следующий запрос

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

Первый рабочий проект OAuth по метаданным RAR и устранению ошибок предлагает более совместимый путь. Сервер ресурса может вернуть HTTP 401 с новой ошибкой insufficient_authorization. Параметр authorization_remediation способен содержать authorization_details, сформированные из неудачного запроса, и необязательный authorization_reference. Затем клиент ищет подходящий ранее полученный токен либо помещает предложенные детали прямо в новый запрос OAuth.

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

Документ датирован 23 августа 2026 года и находится в работе группы OAuth. Он сменил индивидуальный проект после того, как в протоколе заседания OAuth на IETF 126 были отмечены поддержка постановки задачи, спор о решении и намерение провести принятие в рабочую группу. Это не RFC, для него не назначено заседание IESG, и он не содержит результатов внедрения. Предлагаемые регистрации ещё не являются завершёнными назначениями IANA.

Такая оговорка не умаляет ценность идеи. Сервер, способный точно выразить недостающее полномочие, полезнее сервера с одним словом «запрещено». Но полезный ответ не нейтрален: вместе с диагностикой клиент получает проект нового объёма власти.

Сервер ресурса предлагает достаточность, но не выдаёт доступ

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

До действующего полномочия предложение проходит несколько границ контроля. Клиент решает, обрабатывать ли challenge. Сервер авторизации проверяет тип деталей, применяет собственную политику и проводит соответствующий grant. RFC 9396 требует показать запрашиваемые права для согласия; владелец ресурса может разрешить лишь часть или отказать полностью. Ответ с токеном сообщает детали, которые фактически выданы. После этого сервер ресурса заново оценивает токен и операцию.

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

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

Размер JSON здесь ничего не доказывает. RFC 9396 прямо указывает, что произвольные наборы деталей авторизации нельзя сравнивать универсально: семантику полей задаёт конкретный API. Меньшее число свойств не обязательно означает меньше власти. Отсутствующий лимит может включить значение по умолчанию, массив — обозначать объединение, а идентификатор ресурса — полностью сменить защищаемый объект.

Непрозрачная ссылка — ключ поиска, а не решение политики

Необязательный authorization_reference нужен, чтобы при выборе токена клиенту не приходилось понимать сложный объект. Сервер ресурса должен получать стабильное непрозрачное значение для одинаковых или семантически эквивалентных деталей. Клиент сравнивает его со ссылками, сохранёнными рядом с токенами той же пользовательской сессии и того же origin сервера ресурса.

Назначение намеренно узкое. Клиент не толкует значение и не переносит его между разными серверами. Для одноразовых токенов сервер не должен его отправлять. Даже совпадение не гарантирует успех: согласие могло быть отозвано, риск — измениться, а сервер авторизации — выдать только часть запрошенного.

Различие ссылок также не доказывает расширение полномочий. В проекте приведён пример: токен для регулярных списаний до 100 способен покрыть запрос на 80, хотя ссылки различаются. Включение — семантическое отношение, а не равенство непрозрачных строк. Ссылка ускоряет поиск кандидата в хранилище токенов; последнее слово всё равно остаётся за ресурсом.

Эта граница легко исчезает в телеметрии. Запись «ссылка совпала» может отображаться как «авторизация достаточна», хотя она подтверждает лишь выбор возможного credential. И наоборот, «ссылка изменилась» может автоматически запустить новый процесс, не показывая, изменился ли по существу запрошенный объём власти.

Схема проверяет форму, а не назначение

Редакция 00 предлагает точку метаданных для типов деталей авторизации. Тип может публиковать информационную версию, описание, ссылку на документацию, примеры и встроенную JSON Schema либо schema_uri. Схема должна описывать один объект и ограничивать поле type соответствующим идентификатором.

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

Происхождение схемы всё же имеет значение. Если клиент получил предложение при одной версии определения, а запросил полномочия после его изменения, одинаково выглядящие поля могут означать разное. Оператору нужны документ или digest схемы, использованные при проверке, а также версия реализации политики. Одного имени типа для этого недостаточно.

Метаданные могут изменить и маршрут доверия. Если текущий сервер авторизации не поддерживает нужный тип, проект допускает обнаружение альтернативных серверов через Protected Resource Metadata. Это полезно для совместимости, но новый issuer — не прозрачная цель повторной попытки. У него могут отличаться регистрация клиентов, аутентификация, согласие, хранение данных и правила контроля.

Журнал изменения полномочий

Я предлагаю журнал изменения полномочий. Это не новый OAuth claim, заголовок, реестр или требование протокола. Это операционная запись вокруг процесса ремедиации, не позволяющая успешному восстановлению стереть тот факт, что в систему поступило новое предложение власти.

Запись начинается с отказа. Она обозначает пользовательскую сессию и origin сервера ресурса, фиксирует криптографическое обязательство по неудачному запросу и классу операции, а также эффективные scopes или детали авторизации предъявленного токена. Номера счетов, медицинские сведения и чувствительные условия транзакции не переносятся в общий журнал: достаточно узких непрозрачных ссылок или краткоживущих salted commitments.

Затем сохраняется предложение: digest декодированного authorization_remediation, безопасное понятное описание требуемого эффекта, ссылка, тип деталей, URI либо digest схемы, информационная версия и время получения метаданных. Клиент отмечает, счёл ли он полномочия неизменными, более узкими, более широкими, несопоставимыми или неизвестными, и называет специализированный модуль сравнения с версией политики.

Следующий блок — реакция. Клиент отклонил challenge, нашёл прежний токен, начал новый процесс, запросил подтверждение или передал случай оператору? Какой сервер авторизации был выбран и сменился ли issuer? Какая версия экрана согласия показана? Что владелец ресурса одобрил, сузил или отверг? Какие детали ответ с токеном назвал реально выданными?

Наконец, журнал следует за повтором. Привязка ссылки хранится только внутри нужной сессии и origin; отдельно считаются попытка с кэшированным токеном и свежая авторизация; записываются последнее решение ресурса и результат операции либо ссылка на откат. Сам токен, секрет или полный чувствительный RAR-объект не копируются ради удобства аудита.

Так каждый участник подтверждает ограниченное утверждение. Сервер ресурса — что он предложил; клиент — как обработал; сервер авторизации — что показал и выдал; владелец — какое решение принял. Конечный ответ ресурса связывается с цепочкой, но успешный обмен OAuth не выдаётся за доказательство корректного завершения бизнес-операции.

Приватность — часть контроля, а не исключение из учёта

Объекты RAR способны описывать банковские счета, медицинские записи, местоположение и условия транзакций. Проект советует серверам ресурсов не помещать чувствительные данные в исполнимые детали и допускает непрозрачные handles. Серверы авторизации должны учитывать приватность и размер токена перед включением деталей в JWT; в подходящих случаях можно использовать аутентифицированную introspection.

Журнал изменения должен быть столь же сдержанным. Его задача — сохранить отношения между решениями, а не создать вторую базу защищённого содержимого. Одно хеширование не анонимизирует предсказуемые значения: обозначения счетов и суммы с малой энтропией можно перебрать. Обязательствам нужны соль, срок хранения и контроль доступа. Читаемое описание должно передавать минимально необходимый эффект — например, «создать регулярное списание до лимита политики», — не копируя номер счёта.

Важно разделять происхождение сведений. Handle, присланный сервером ресурса, не является показанием пользователя. Описание схемы — не текст согласия. Выданные в токене детали не доказывают, что человек прочитал интерфейс. Метки происхождения усложняют запись, но делают её честной.

Восстановление после ошибки может стать автоматизацией политики

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

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

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

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

Источники

  1. Проект о метаданных RAR и ремедиации
  2. История редакций проекта
  3. Запись API Datatracker
  4. Редакция 00 рабочей группы
  5. Текст редакции 00
  6. Репозиторий исходного индивидуального проекта
  7. Протокол OAuth на IETF 126
  8. Устав рабочей группы OAuth
  9. RFC 9396: Rich Authorization Requests
  10. RFC 6750: Bearer Token Usage
  11. RFC 8414: Authorization Server Metadata
  12. RFC 9728: Protected Resource Metadata
  13. RFC 9470: Step Up Authentication Challenge
  14. RFC 7662: Token Introspection
  15. RFC 9068: JWT Access Token Profile
  16. RFC 9126: Pushed Authorization Requests
  17. RFC 9101: JWT-Secured Authorization Request
  18. Параметры OAuth в IANA
  19. XML-источник редакции 00
  20. Issues прежнего репозитория