Кратко

  • 24 августа 2026 года IESG одобрил редакцию 10 draft-ietf-oauth-rfc8725bis как Best Current Practice. На момент фиксации доказательств документ оставался Internet-Draft в очереди RFC Editor; после публикации он сделает RFC 8725 устаревшим и обновит RFC 7519.
  • Главная эксплуатационная норма — взаимная исключительность правил для разных видов JWT. Правильной подписи недостаточно: должны совпасть тип, издатель, аудитория, обязательные claims, защищённые заголовки, алгоритм, ключ и прикладной контекст.

Событие безопасности у платёжного шлюза

Представим, что одна система получает Security Event Tokens об изменениях учётных записей, а соседний API принимает токены доступа. Оба потребителя доверяют одному издателю и одному набору ключей. Настоящий, правильно подписанный токен события попадает в API. Общая JWT-библиотека проверяет подпись и сообщает об успехе.

Криптография сработала. Граница полномочий — нет.

Это иллюстративная проверка, а не описание известной атаки. Она показывает cross-JWT confusion: объект, выпущенный для одной цели, подставляют в контекст другой. Подделывать подпись не требуется, если получатель превращает утверждение «издатель действительно сказал это» в вывод «издатель разрешил это действие здесь».

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

Одобрение ещё не означает выпуск RFC

В объявлении IESG зафиксировано: десятая редакция «JSON Web Token Best Current Practices», подготовленная рабочей группой OAuth, одобрена 24 августа в 18:02 UTC для публикации в качестве BCP.

28 августа Datatracker всё ещё показывал активный Internet-Draft от 21 августа, обновлённый 25 августа и истекающий 22 февраля 2027 года. Состояние IESG — RFC Ed Queue. RFC Editor ожидал ещё не полученную ссылку. IANA не планировала новых регистрационных действий, хотя статус процесса оставался текущим.

Таким образом, решение по стандарту принято, но номера RFC, завершённой редакционной публикации и доказанного внедрения пока нет. При выпуске в заявленном виде документ заменит RFC 8725 и обновит базовую спецификацию JWT — RFC 7519.

Четыре решения внутри слов «JWT действителен»

JWT — формат claims, а не единый способ защиты. Он может быть подписанным JWS, зашифрованным JWE, вложенным объектом или, если приложение это явно допускает, unsecured JWT. Компактная запись с base64url и точками также не тождественна всем JSON-сериализациям JOSE.

Получатель должен последовательно установить:

  1. соответствует ли объект именно той сериализации, которую принимает endpoint;
  2. проходит ли подпись или аутентифицированное шифрование с разрешённым алгоритмом и нужным ключом;
  3. относится ли объект к виду токена, для которого создан этот потребитель;
  4. разрешают ли claims эту операцию сейчас, для данного издателя, аудитории и субъекта.

Расшифрование JWE не проверяет автоматически подпись вложенного JWT. Успешный разбор компактной формы не создаёт доверия. Верная подпись JWS не делает его claims применимыми во всех службах, знающих тот же ключ.

typ должен исключать чужой класс

При риске смешения редакция рекомендует явную типизацию. Тип Security Event Token из RFC 8417 даёт потребителю различитель до интерпретации claims. Общее значение JWT сообщает лишь семейство контейнера и не называет прикладной договор.

Одного типа недостаточно. Множества, принимаемые валидаторами разных видов токенов, должны быть взаимоисключающими. Границу можно провести разными явными типами, обязательными claims или значениями, защищёнными заголовками, ключами, аудиториями или издателями.

RFC 9068 задаёт JWT-профиль для OAuth access tokens, а RFC 8417 — для событий безопасности. Оба могут быть подлинными, но не взаимозаменяемыми. Получатель выбирает профиль до того, как превратить поля в полномочия.

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

Общая компания не создаёт общую аудиторию

iss называет того, кто сделал утверждение; aud ограничивает его адресатов. Оба значения проверяются по выбранному профилю до того, как claims повлияют на маршрутизацию, права или данные.

Сервисы A и B не становятся одной аудиторией из-за общего владельца или провайдера идентификации. Токен для A не приобретает полномочий в B только благодаря общей администрации.

У sub тоже нет универсального смысла. Поле может обозначать человека, клиентское приложение или предмет события безопасности. Значение задаёт профиль, а не одно имя поля.

Токен не выбирает способ собственной проверки

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

Заголовки выбора ключей kid, jku и x5u могут запускать запросы или удалённую загрузку. Без ограничений они открывают пути для инъекции и запросов сервера к произвольным адресам. До проверки это ввод атакующего; после проверки он всё равно не даёт издателю неограниченного сетевого доступа.

Новая редакция охватывает минимальную трудоёмкость парольного шифрования, пределы распаковки JWE и полностью определённые идентификаторы алгоритмов из RFC 9864. Это защита от истощения ресурсов и двусмысленности, а не только от подделки.

Что сохраняет доказательство авторизации

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

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

Источники