Кратко

  • «Активен» в RFC 9767 — это совокупность условий выдачи, отзыва, времени, proof, адресата и запрошенного доступа в контексте вызывающего RS.
  • Сервер авторизации сообщает состояние токена. Сервер ресурсов отдельно проверяет текущую презентацию, применяет свою политику и выбирает реальный ответ.
  • Надёжный журнал разделяет четыре квитанции: интроспекцию, доказательство сообщения, локальное решение и наблюдаемый эффект; возраст кэша и производный токен не скрываются.

Кто задал вопрос

Клиент предъявляет токен серверу ресурсов RS. Тот обращается к серверу авторизации AS. Запрос подписывает сам RS своим ключом — не клиент и не ключ токена. Так сторона, которая собирается действовать над ресурсом, явно называет себя.

В теле находятся значение токена, рекомендуемый способ proof, идентификатор RS и, при необходимости, минимальные права для операции. AS обязан учесть каждый параметр. Если часть контекста ему непонятна, отвечать active нельзя.

Отсюда следует первый предел: активность не является вечным свойством строки токена. Артефакт может подходить RS1 и не подходить RS2, разрешать чтение и не разрешать запись, быть не просроченным, но предъявленным с неправильным доказательством.

RFC 9767 дополняет основной GNAP. RFC 9635 определяет grant между клиентом и AS, а расширение соединяет отдельно развёрнутые AS и RS. Общая форма сообщения передаёт сведения, но не превращает AS в владельца всех прикладных решений.

Как AS узнаёт ключ RS, стандарт не определяет. Возможны предварительная регистрация или trust on first use. Проверенная подпись доказывает владение признанным ключом, но не правильность организационной регистрации и не будущую добросовестность RS.

Условия положительного ответа

Для true токен должен быть выдан отвечающим AS, не отозван и не просрочен, связан указанным способом proof, пригоден для названного RS и удовлетворять access, если это поле передано.

False не является кодом одной причины. Он охватывает отзыв, срок, неверную аудиторию, недостаточный доступ и неопределённость, включая отсутствие токена в данных AS. Остальные поля при этом опускаются. Запись «отозван» для любого false добавляет несуществующий факт.

True тоже не шире определения. Он не доказывает текущую волю пользователя, корректность тела, наличие объекта, лимит, антифрод, выполнение записи или доставку ответа. Это вердикт о токене в вопросе, а не результат операции.

При положительном ответе AS может вернуть права, ключ, flags, время и идентификаторы. Права разрешено фильтровать для данного RS, вплоть до пустого массива. Значение токена возвращать нельзя. RS получает необходимую проекцию, а не полный grant.

Локальное право на ответ

После интроспекции RFC 9767 прямо оставляет RS выбор дальнейшего действия. При недостатке прав он может выдать ошибку либо публичный ресурс. Окончательный ответ находится в его усмотрении.

Это не обход авторизации, а правильная точка управления. AS знает выдачу, grant и отзыв. RS знает метод, endpoint, состояние объекта, локальные ограничения и то, какие ответы он способен выполнить.

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

Эффект также отделён. Запись могла commit-нуться, а ответ потеряться. Запрос мог быть принят, но нижележащее хранилище отказало. HTTP 200 может содержать прикладную ошибку. AS этого не наблюдал.

Две проверки вместо одного флага

У токена, связанного с ключом, проверяются и сам токен, и proof текущего сообщения. Одной корректной подписи мало: скомпрометированный ключ или confused deputy способен подписать действие за пределами прав.

Положительная интроспекция, в свою очередь, не проверяет автоматически текущую подпись, target, nonce и покрытые компоненты. RFC 9767 требует независимого proof для каждого запроса и запрещает переносить закэшированный результат с одного сообщения на другое.

HTTP Message Signatures, DPoP и сертификатно-связанные токены предлагают разные способы привязки. Ни один не заменяет политику RS. Поэтому журнал proof хранит ID сообщения, компоненты, ключ, алгоритм, свежесть и результат отдельно от ID интроспекции.

Кэш как выбор времени

Живая интроспекция добавляет задержку и зависимость от доступности AS. RS может кэшировать результат, получая производительность ценой меньшей актуальности и точности. Уже отозванный токен может пройти по старому положительному значению.

TTL — решение оператора ресурса. Оно говорит, сколько времени RS готов подменять настоящее состояние прошлым фактом AS. Публичное чтение и необратимый платёж не должны случайно иметь одинаковое окно из настройки SDK.

Ключ кэша должен включать контекст: token, RS, способ proof и требуемый access. Ключ только по токену расширяет узкий ответ. Долгий отрицательный кэш тоже опасен, поскольку false включает неопределённость и может скрыть восстановление.

RFC 7009 описывает отзыв на стороне AS, а не доказанное удаление результата во всех RS. RFC 9767 упоминает активный сигнал, но оставляет механизм вне области. Замыкание требует события инвалидирования, списка затронутых записей и последующего изменившегося решения.

Минимальное раскрытие и новая видимость

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

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

Различается и ключевой материал. Открытый асимметричный ключ не даёт создать закрытую подпись. Симметричный секрет, переданный RS, может позволить ему сформировать новое предъявление. Одного термина «key-bound» недостаточно для оценки повторного использования.

Идентификатор ссылки на ресурсы должен оставаться непрозрачным. Если клиент или RS разбирают внутренний формат, появляются утечка и зависимость. Случайное или зашифрованное значение сохраняет идентификатор как ссылку на смысл у AS, а не самостоятельное право.

Новый токен — новый участок ответственности

RS1 иногда должен вызвать RS2. Передавать входящий bearer token опасно: смешиваются действующие лица и растёт риск утечки. RFC 9767 позволяет RS1 предъявить existing_access_token, идентифицироваться клиентом с собственным ключом и подписать новый grant-запрос.

AS проверяет пригодность исходного токена для RS1 и может выдать более узкий токен для RS2, связанный с RS1. Следующий сервис способен повторить схему.

Производность не доказывает сквозное выполнение. Токен RS2 не подтверждает, что RS1 верно понял запрос, RS2 сделал работу, а результат вернулся клиенту. Как и OAuth Token Exchange, новый артефакт требует заново учитывать actor, subject, audience и scope.

Четыре квитанции

Первая квитанция — полный запрос и ответ интроспекции, подписанный RS, время и кэш. Вторая — proof конкретного сообщения. Третья — политика и выбор RS. Четвёртая — commit, подтверждение нижнего сервиса, доставка или компенсация.

Испытания разрывают стыки: верный токен на неверном RS; лишний access; неизвестный параметр; повтор proof; старый true после отзыва; пустые отфильтрованные права; commit без ответа; прямое использование входящего bearer на RS2. Система надёжна, когда каждая часть ограничивает себя собственным доказательством.

Источники