Кратко

  • RFC 7662 позволяет защищённому ресурсу узнать у сервера авторизации текущее состояние токена и получить сведения, предназначенные для этого ресурса.
  • active: true — содержательный вывод о токене, но не разрешение запрошенного действия, не запись о выполнении и не долговечная квитанция о результате.
  • Кэширование снижает нагрузку и задержку ценой актуальности, поэтому состояние токена, локальное решение и эффект приложения требуют отдельных доказательств.

Зелёный сигнал относится к токену

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

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

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

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

Интерфейс Richer соединяет, но не смешивает полномочия

Justin Richer указан автором RFC 7662 — документа IETF Standards Track об интроспекции токенов OAuth 2.0. Важно не превращать корректную атрибуцию в легенду об единоличном авторстве. Стандарт создан в процессе IETF и не даёт Richer контроля над чужими реализациями или эксплуатационными решениями.

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

Такое разделение уже заложено в ролях OAuth. Клиент предъявляет токен доступа серверу ресурса. Тот проверяет токен и обслуживает запрос, когда выполнены его условия. RFC 6750 описывает этот путь для bearer-токенов. Интроспекция стандартизирует источник проверочных данных, но не создаёт прикладное правило, связывающее область доступа с каждой операцией.

Журнал аудита должен хранить оба вывода. Какой сервер авторизации, когда и для какого ресурса признал токен активным? Какая версия локальной политики разрешила или запретила какой запрос? Одна запись «авторизовано» удобна для счётчика, но не объясняет инцидент.

Ответ зависит от того, кто спрашивает

Интроспекция не обязана выдавать всем полный и одинаковый паспорт токена. RFC 7662 разрешает серверу авторизации формировать ответ с учётом защищённого ресурса, который обращается к нему. В частности, можно вернуть только те области доступа, которые относятся к этому ресурсу. Так снижается лишнее раскрытие данных, а смысл ответа остаётся привязанным к адресату.

Следовательно, результат в журнале сервиса A не доказывает, что сервис B увидел бы то же самое. Вместе с ответом нужны идентификатор спрашивающего ресурса, аудитория, время и фактически раскрытые поля. Разные ответы могут быть намеренными и корректными.

RFC 8707 проводит соседнюю границу. Указатель ресурса сообщает, где предполагается использовать токен; scope описывает, какой доступ запрашивается. «Где» и «что» дополняют друг друга, но не фиксируют исход отдельной бизнес-команды.

Не следует менять смысл необязательных полей. exp и nbf задают время, aud и iss помогают установить аудиторию и издателя, а sub, username и client_id могут указывать на разные роли. jti идентифицирует токен. Один токен обычно используется во многих запросах, поэтому его идентификатор не становится номером заказа, перевода или выполнения.

Кэш хранит недавнее прошлое

Интроспекция для каждого вызова создаёт нагрузку на сервер авторизации и добавляет сетевой переход в критический путь. RFC 7662 разрешает кэшировать ответы. Одновременно она прямо указывает цену: производительность приобретается за счёт живости информации.

Пусть ресурс получил активный статус в 10:00 и сохранил его на пять минут. В 10:01 владелец отзывает токен механизмом RFC 7009 или администратор прекращает выдачу полномочий. До 10:05 ресурс может продолжать пользоваться прежним ответом. Сервер авторизации уже знает новое состояние, а ресурс следует старому снимку в пределах своей настройки.

TTL кэша становится решением по безопасности, а не только оптимизацией. Его нужно связывать со сроком токена, обещанной скоростью отзыва, чувствительностью операции, доступностью сервера и ценой ошибочного допуска. Чтение открытого каталога и смена средств восстановления не должны получать одинаковое окно устаревания только из-за общего клиента интроспекции.

Отзыв также не меняет прошлое. RFC 7009 делает токен недействительным и, в зависимости от реализации, может затронуть связанные токены или полномочия. Но он не возвращает уже раскрытый секрет, не отменяет проведённый внешний платёж и не забирает доставленное сообщение. Блокировка будущего использования и исправление последствий — разные процессы.

После допуска ещё нужно установить результат

Даже разрешённый локальной политикой запрос может закончиться неоднозначно. Сервис падает до фиксации или фиксирует изменение, но теряет ответ. Очередь принимает команду, а исполнитель отклоняет её позже. Клиент повторяет вызов с тем же активным токеном. Два технически допустимых запроса могут представлять одно намерение и вызвать два эффекта.

В интроспекции нет квитанции на такой случай. Scope обозначает класс доступа. jti связывает использования одного токена. Успешная интроспекция доказывает, что сведения о токене были возвращены, но ничего не говорит о конечном состоянии приложения.

Для значимых API нужен долговечный идентификатор операции: ключ идемпотентности, идентификатор команды, условие по версии или другой механизм предметной области. После тайм-аута результат должен быть доступен по этому идентификатору. Проверка токена, локальное решение, операция, фиксация состояния и доставка ответа могут быть связаны, но не заменяют друг друга.

Строгое прочтение RFC 7662 не умаляет интроспекцию. Оно сохраняет силу стандартизированного ответа на узкий и трудный вопрос. Когда этот ответ не заставляют свидетельствовать о невидимых ему решениях, становится ясно, где системе нужны остальные доказательства.

Источники