Кратко

  • Индивидуальный Internet-Draft от 29 сентября предлагает краткоживущий токен доступа OAuth для одного сервера ресурсов с проверкой политики сервером авторизации при каждом запросе. Документ находится в состоянии I-D Exists; он не стал стандартом и не подтверждает работу системы в эксплуатации.
  • Если одна задача обращается к двум серверам, значения txn должны отличаться, а внутреннее соответствие остаётся у сервера авторизации. Проект прямо предупреждает: общая client_id, другие поля и близкое время выдачи могут всё же связать действия.

Представим клиента, которому для законной задачи нужны два сервиса. Обычный scope сообщает, какие действия разрешены вообще, но не всегда объясняет конкретный повод для текущего вызова. draft-tulshi-oauth-transactional-access-tokens-00 предлагает серверу авторизации принимать решение заново для каждой транзакции и выдавать адресный txnat+jwt с утверждённым контекстом. В качестве важного применения названы ИИ-агенты, но это не доказательство внедрения или защищённости какой-либо действующей системы. Datatracker относит текст к индивидуальным проектам с предполагаемым направлением Standards Track, без номера RFC и принятия рабочей группой.

Ключевой выбор скрыт в распределении права сопоставлять записи. Сервер авторизации создаёт внутренний идентификатор, не раскрываемый клиенту и серверам ресурсов. Первому адресату он выдаёт токен с единственным aud и локальным значением txn. Если задача требует второго ресурса, клиент с непрозрачным дескриптором транзакции просит ещё один токен. Новый txn должен отличаться; получатели не должны устанавливать общий источник только по сравнению этих двух значений. Выпускающий сервер, напротив, сохраняет внутреннюю связь и может объединить журналы для аудита. У каждого сервиса — свой фрагмент, у центрального узла — общая картина.

Однако конфиденциальность здесь ограничена конкретным полем. В разделе 8 проект отмечает, что client_id одинакова для разных серверов ресурсов. Авторы советуют парные идентификаторы субъекта и минимум стабильных данных в контексте, но допускают корреляцию по близкому времени выпуска у серверов, которые обмениваются наблюдениями. Разные значения txn убирают один удобный ключ соединения, не все признаки. Сервер авторизации сам становится хранителем чувствительного соответствия; сроки хранения и доступ к нему нельзя оставлять без правил.

Есть и разница между коротким токеном и долгим правом его получать. Проект рекомендует не более 300 секунд между iat и exp, но refresh token или учётные данные клиента могут жить дольше. Выигрыш возникает, если сервер авторизации действительно проверяет каждый запрос и способен отклонить отдельную транзакцию при действительном исходном праве. В течение срока действия bearer-токен допускает повторное предъявление; привязка к отправителю рекомендована, но разовость не установлена как всеобщее требование. Срок жизни не доказывает законность задачи.

Прежний проект OAuth Transaction Tokens касается передачи контекста внутри одной доверенной области. Ранее BTW разбирал происхождение утверждений в подписанном внутреннем токене. Здесь другая граница: транзакционный токен доступа выходит к конкретному внешнему серверу ресурсов, а возможность связать журналы разных адресатов остаётся у органа выдачи. Наличие локального txn в журнале полезно, но не восстанавливает межсерверную цепочку без центрального соответствия.

Источники