Кратко

  • RFC 9701 позволяет аутентифицированному resource server получить подписанный и при необходимости зашифрованный JWT-ответ интроспекции с iss, aud, iat и вложенным состоянием токена.
  • Полная квитанция отдельно связывает личность вызывающего сервера, тип, ключ и алгоритм, подпись и расшифрование, audience и возраст, внутренние active и scope, основание раскрытия, replay-проверку, локальное правило и выполненный результат.

В 12:00 сервер авторизации подписал active:true. В 12:01 токен отозвали. В 12:02 подпись старого ответа по-прежнему проверяется. Криптография не ошиблась: она подтверждает прошлое утверждение. Ошибётся ресурс, если примет историческую подлинность за текущее право.

RFC 9701 добавляет JWT-ответ к механизму RFC 7662. Обычная интроспекция возвращает JSON о состоянии access token. Новый формат позволяет связать ответ с сервером авторизации и при необходимости скрыть его от посторонних. Но он остаётся входом в решение, а не решением.

Сначала авторизуется тот, кто спрашивает

Authorization server обязан идентифицировать, аутентифицировать и авторизовать resource server. TLS-соединение само по себе не показывает, является ли этот сервер audience токена и какие поля ему разрешено получить. Неаутентифицированный вызов должен быть отвергнут.

Resource server можно зарегистрировать как OAuth-клиент с помощью RFC 7591, выдав ему ограниченные credentials и ключи. Это один вариант управления. Независимо от реализации результат должен быть одинаков: вызывающая сторона известна, её полномочия ограничены, выдаваемые данные привязаны к ней.

Если токен недействителен, истёк, отозван или не предназначен для вызывающего сервера, вложенный объект содержит только active:false. При положительном ответе scope следует сузить до релевантного данному ресурсу. Персональные claims выдаются по отдельной политике и законному основанию.

Внешнее время датирует ответ, внутреннее — токен

Resource server отправляет Accept: application/token-introspection+jwt. Ответ и JWT header используют соответствующий media type и typ. На верхнем уровне обязательны iss, aud, iat и token_introspection.

Внешний aud определяет адресата ответа. Внутренний aud может определять адресата access token. Внешний iat говорит, когда создана квитанция; внутренние даты относятся к жизненному циклу токена. Одинаковые имена не разрешают удалить вложенность.

RFC не рекомендует внешний sub или exp и прямо говорит: JWT-ответ не является альтернативным представлением исследуемого токена и не должен использоваться как access token. Реестры IANA для OAuth, JWT и media type стандартизуют словарь, но не контролируют модель данных конкретного продукта.

Подпись сохраняет высказывание, шифрование ограничивает читателя

Ответ подписывается либо сначала подписывается, затем шифруется как Nested JWT. JWS, JWE и JWT задают форматы. Локальная система выбирает доверенные issuer, ключи, допустимые algorithms, ротацию и возраст ответа.

RFC 9701 вводит метаданные алгоритмов подписи, шифрования ключа и контента. Authorization server может публиковать поддержку через RFC 8414. Список возможностей не доказывает, какой алгоритм использован сейчас. kid помогает найти ключ, но не доказывает, что этот ключ был разрешён данной версией политики.

В квитанции нужны hash ответа, typ, ожидаемый issuer, версия issuer-bound key set, algorithm policy, фактические alg и kid, результаты подписи и при JWE — ключ получателя и расшифрование. Фраза «JWT валиден» не позволяет восстановить эти решения.

Подлинный JWT может быть принят не в той юрисдикции

JWT access token и ответ интроспекции могут иметь похожие iss, aud и подпись. Если вход принимает любой подписанный JWT, ответ можно подставить вместо токена. RFC 9701 использует выделенный typ и вложенный объект; RFC 8725 требует явных и взаимоисключающих профилей проверки.

У каждого входа должны быть свои type, issuer, audience, обязательные claims и алгоритмы. Успешное расшифрование не меняет назначение объекта.

Подпись ответа также не привязывает исходный токен к предъявителю. RFC 9701 ссылается на RFC 9700 для защиты от replay. Sender constraint, proof-of-possession, request binding и token audience проверяются отдельно. Подлинное сообщение о состоянии токена не доказывает право этого участника применять его.

Возраст доказательства зависит от операции

Внешний iat позволяет вычислить возраст, но не задаёт общий TTL. Для чтения некритичного профиля допустимый возраст может быть одним, для необратимого платежа — другим. После порога нужна новая интроспекция или иной механизм.

Старый ответ полезен для расследования: он показывает, что говорил authorization server. Он не сохраняет операционную силу. Оптимизация cache без явной политики свежести превращает прошлое разрешение в скрытое продление.

Затем resource server применяет собственные правила. scope=write не снимает блокировку объекта, не отменяет приостановку аккаунта, лимит суммы, дополнительное согласование или географический запрет. Локальный allow — ещё не эффект: запись может не выполниться или откатиться. Требуется отдельная квитанция результата.

Интроспекция создаёт наблюдение о пользователе

Ответ может содержать PII. RFC 9701 требует правового основания и его исполнения по отношению к конкретному resource server. Шифрование препятствует чтению без ключа, но не оправдывает лишние claims и не управляет их последующим использованием. RFC 9325 укрепляет TLS, не заменяя политику раскрытия.

Сам запрос сообщает authorization server, когда клиент и, возможно, пользователь обращаются к ресурсу. Если это неприемлемо, спецификация требует другой способ передачи token data. Значит, выбор интроспекции — ещё и выбор телеметрии.

Полная цепочка связывает fingerprint токена, операцию, identity и authentication ресурса, endpoint/TLS, hash ответа, type, key, signature/decryption, внешние claims, внутреннее состояние и scope, основание раскрытия, replay-check, версию локальной политики, решение, эффект и компенсацию.

Доктрина Lu Heng о минимальной начальной спецификации оставляет в общем слое формат и обязательные claims, а доверие, свежесть, приватность и авторизацию сохраняет локальными и видимыми. Reality layers разделяют реестр, байты, подпись, состояние, решение и эффект. Running-code primacy требует реальную трассу verifier и enforcement вместо заявления о поддержке.

Источники