Кратко

  • draft-ietf-oauth-deferred-token-response-00 представляет один ожидающий запрос через привязанный к отправителю deferral_code; это не access token и он не даёт доступа к ресурсу.
  • Endpoint RFC 7009 отвечает HTTP 200 и при успешной отмене, и без изменения состояния. Объявленная поддержка и последующий poll с access_denied — разные доказательства.
  • Уже доставленный access token — самостоятельная credential со своим сроком. Отмена кода отсрочки не отзывает её и не доказывает остановку операции.

Успешный ответ, который отказывается свидетельствовать

OAuth revocation не сообщает вызывающей стороне, был ли представленный токен действительным. Так endpoint хуже подходит для перебора секретов. Но по той же причине его HTTP-статус не может служить отражением внутреннего состояния.

Deferred Token Response версии 00 описывает решения, которые не помещаются в исходный запрос: ручную проверку, антифрод или внешний контроль. Если клиент допускает отложенное завершение и сервер его выбирает, token endpoint возвращает HTTP 400, authorization_pending, непрозрачный код, срок и минимальный интервал poll.

Код обозначает один ожидающий запрос у того же сервера. Он не является access, refresh или authorization token. При DPoP либо mTLS он остаётся связан с тем же ключом или сертификатом. Знание строки без привязки не создаёт то же право.

Документ остаётся активным Internet-Draft рабочей группы OAuth, а не RFC и не отчётом о внедрении. Его состояния можно анализировать, не приписывая их уже работающим сервисам.

Одинаковое поле, разные часы

Первый expires_in задаёт жизнь кода отсрочки. После неё poll получает expired_token. Успешный окончательный ответ может содержать ещё один expires_in, уже для access token. Один таймер в интерфейсе потеряет владельца времени.

Значение interval приходит только в первом ответе и должно сохраняться. authorization_pending его не повторяет, а slow_down увеличивает минимум на пять секунд. Журнал последних ответов не докажет соблюдение частоты.

Квитанция должна связывать срок с конкретным объектом, клиентом и ключом. Синтаксическое совпадение не переносит полномочия.

Callback будит, но не решает

Зарегистрированный HTTPS endpoint получает уведомление, когда запрос завершился успехом, ошибкой или отменой. В callback есть код отсрочки, но нет токена и результата. Его смысл: следующий poll даст финальный ответ.

Отдельный notification token подтверждает отправителя. Без него нужны другие меры, а сообщение остаётся advisory до poll. Даже аутентифицированный callback не отличает одобрение от отказа.

Draft рекомендует продолжать poll с заданным интервалом. Callback уменьшает задержку; poll переживает потерю, задержку или блокировку уведомления. Превращать сигнал пробуждения в вердикт значит уничтожить независимость каналов.

За одним 200 скрыты несовместимые исходы

Для отмены клиент отправляет точный код в revocation endpoint и рекомендуемый type hint. Если код известен и принадлежит этому клиенту, сервер атомарно переводит запрос в cancelled, подавляет ещё не начатый callback и заставляет следующие polls отвечать access_denied.

Неизвестный или чужой код, уже redeem, cancelled либо expired, также получает HTTP 200 без изменения. Это правило RFC 7009, сохраняющее неразличимость.

DTR вводит revocation_endpoint_token_type_values_supported. Поддерживающий сервер перечисляет тип deferral-code. Не объявивший поддержку сервер всё равно вернёт 200 на любой отзыв. Текст прямо предупреждает: пропуск discovery может оставить отмену молча неисполненной.

Поэтому цепочка начинается со snapshot метаданных, продолжается запросом и транспортным результатом и заканчивается poll с access_denied. 200 — промежуточная квитанция.

Граница доставки определяет оставшуюся credential

Решение может уже быть успешно committed, а токен ещё не доставлен. Если отмена попадает в это окно, код считается redeem, а затем cancelled. Токен не выдаётся, poll возвращает access_denied.

Если токен уже у клиента, отзыв кода не должен отзывать его побочно. Это независимые credentials. Для прекращения доступа нужен отдельный отзыв токена и, при необходимости, проверка поведения resource server.

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

Статусу «отменено» нужна позиция: ещё pending, resolved без доставки либо token delivered. Без неё неизвестно, какое действие требуется дальше.

Согласие может устареть раньше кода

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

Затем resource server применяет scope и локальную policy. Действительный токен не доказывает допуск конкретной операции; допуск не доказывает её бизнес-результат.

Минимальная квитанция сохраняет гонку, а не секрет

Локальная запись включает issuer и digest метаданных поддержки, клиента и ссылку на ключ, одностороннюю корреляцию вместо секретного кода, время, срок, интервал, попытки отмены, финальный poll, состояние callback и факт пересечения границы доставки.

Draft требует защищать код как refresh-token secret и удалять его из общих логов. После доставки добавляется независимый отзыв токена; для реального риска — допуск ресурса и результат контролируемой операции.

Это Minimum Initial Specification для доказательств, а не центральный реестр. По Reality Layers Лу Хэна, 200 — символическое сообщение, отмена — переход состояния, access_denied — наблюдение протокола, отзыв токена — другое credential-событие, а операция ресурса — исполнимый результат. Доказательство усиливается при движении к running code, а не при копировании первого сигнала.

Источники

  1. Deferred Token Response rev00
  2. История DTR
  3. DTR rev00 HTML
  4. Текст DTR rev00
  5. RFC 6749 — OAuth 2.0
  6. RFC 7009 — OAuth Revocation
  7. RFC 8628 — Device Authorization Grant
  8. RFC 8693 — Token Exchange
  9. RFC 8705 — OAuth mTLS
  10. RFC 9449 — OAuth DPoP
  11. RFC 9700 — OAuth Security BCP
  12. IANA OAuth Parameters
  13. Lu Heng — Minimum Initial Specification
  14. Lu Heng — On Reality Layers
  15. Lu Heng — Running Code Primary