Кратко

  • Новый индивидуальный Internet-Draft предлагает выдавать отдельный Txn-AT примерно на пять минут, для одного Resource Server и после новой проверки политики для каждой транзакции.
  • Такая гранулярность ограничивает принимающую сторону, но не превращает несколько независимых действий в атомарную операцию и не доказывает исполнение, однократность или итог.

draft-tulshi-oauth-transactional-access-tokens-00 опубликован 29 сентября 2026 года. Это индивидуальный Internet-Draft с намерением выйти на Standards Track. Он не принят рабочей группой OAuth, не выражает консенсус IETF и не является RFC. В документе нет результатов внедрения, межоперабельности или эксплуатации, поэтому его следует читать как проверяемое архитектурное предложение.

Предлагаемый Txn-AT остаётся JWT-профилем RFC 9068, но получает typ: txnat+jwt. Это не косметика. Получатель, который не знает новый тип, должен отказать, а не принять его как обычный access token. Поле aud указывает ровно один Resource Server. txn обозначает конкретную транзакцию в пределах этой аудитории, а tctx и rctx несут контекст, который Authorization Server уже оценил.

Выдача не начинается с чистого листа. Клиент предъявляет token exchange, refresh token либо client credentials. Authorization Server обязан снова выполнить policy evaluation и может отказать, даже если исходное полномочие ещё действительно. При первой выдаче он также создаёт непрозрачный transaction handle, связанный с клиентом, субъектом и, при наличии sender constraint, с тем же ключом отправителя.

По этому handle клиент может запросить Txn-AT для других ресурсов той же бизнес-операции. Именно здесь удобная модель авторизации сталкивается с моделью исполнения. Каждый ресурс получает собственную аудиторию и собственное значение txn; каждый принимает решение в своё время; ни один токен не управляет общей фиксацией результатов.

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

Транзакционный handle также не является протоколом двухфазной фиксации. Он связывает выдачи у Authorization Server, но не резервирует ресурсы и не заставляет серверы согласованно подготовить, зафиксировать или откатить эффект. Значение txn не является business idempotency key: оно описывает контекст авторизации, а не тождество попыток исполнения.

Поэтому рабочая цепочка доказательств должна быть длиннее JWT. Нужны идентификатор бизнес-запроса, policy receipt с версией и входами решения, audience-specific token, квитанция о приёме, отдельная квитанция о фактическом эффекте и запись о компенсации. Ответ 200 на проверку токена не доказывает, что деньги списаны, право выдано или побочный эффект не повторился.

Короткий срок жизни снижает окно злоупотребления, но не устраняет replay. Bearer Txn-AT можно повторно предъявить в течение его срока. Draft рекомендует DPoP или Mutual TLS и допускает отслеживание jti, однако это разные свойства. Sender constraint связывает токен с ключом; jti-state обнаруживает повтор; идемпотентность не допускает второго бизнес-эффекта. Одно нельзя выдавать за другое.

Долговечное полномочие остаётся за коротким токеном. Refresh token, client credential и ранее полученное consent позволяют запрашивать новые решения без нового участия пользователя. Похищенная основа ещё должна пройти текущую политику, но злоумышленник сохраняет способность снова обращаться к решающему центру. Пять минут описывают жизнь одного артефакта, а не жизнь права просить следующий.

Концентрация решений в Authorization Server даёт наблюдаемость, но также создаёт критический путь. Латентность выдачи входит в каждую операцию; отказ сервера останавливает защищённые действия; региональные реплики должны согласовать policy versions, handles, signing keys, revoked credentials и replay-сигналы. Валидная подпись не доказывает, что два региона ответили по одной политике.

Privacy-выгода от audience-specific txn тоже ограничена. RS1 и RS2 не могут просто сравнить один глобальный идентификатор, однако остаются client_id, субъект, время, характерный контекст и бизнес-идентификаторы. Сам Authorization Server видит все запросы и внутреннюю связь. Боковая корреляция уменьшается ценой более сильной центральной наблюдаемости.

Draft предлагает выводить audience-specific txn через HMAC от внутреннего идентификатора и аудитории. Это сокращает таблицу соответствий, но превращает K_txn, его ротацию и retired keys в часть аудита. Потеря ключа и внутренней записи вместе может лишить оператора возможности восстановить связь между ресурсами именно тогда, когда расследуется частичная фиксация.

Модель полезна там, где она остаётся тонкой. Она может переносить тип токена, ограниченную аудиторию, происхождение и оценённый контекст. Она не должна превращать Authorization Server в универсального владельца бизнес-истины, а приём токена — в доказательство результата. Контроль сохраняется лишь тогда, когда каждый слой сообщает только собственное решение.

Источники