Кратко

  • Привязанный к ключу клиента continuation access token в GNAP продолжает конкретный запрос на грант, а не вызывает защищённый ресурс.
  • Пока запрос находится в pending, RFC 9635 не разрешает выдать API token или раскрыть сведения о субъекте. Завершившееся взаимодействие всё ещё требует новой оценки сервером авторизации.

Сообщение о том, что пользователь завершил шаг согласия, легко принять за итог. Но оно может означать лишь возврат браузера к клиенту, получение URI продолжения или подпись, подтверждающую владение ключом. Ни один из этих фактов сам по себе не отвечает на главный вопрос: вправе ли этот клиент сейчас выполнить этот вызов к данному API?

RFC 9635 строит GNAP именно против такого сокращения смысла. Клиент подаёт запрос на грант серверу авторизации. Если ещё нужны согласие владельца ресурса или взаимодействие с пользователем, запрос становится pending. Сервер может вернуть сведения для продолжения, но не может выдать токены доступа к API или сведения о субъекте. Доступ ещё обсуждается, а не выдан.

У учётных данных продолжения намеренно узкая работа. Они должны быть связаны с ключом экземпляра клиента, не могут быть bearer token и предъявляются вместе с доказательством этого ключа на URI продолжения. Сервер авторизации проверяет подпись и связь с нужным ключом. Это защищает того, кто вправе продолжать тот же разговор. Это не создаёт разрешение у сервера ресурсов.

Разделение обязательно в обе стороны. Обычный access token не должен работать на endpoint продолжения. И наоборот, token продолжения не должен служить для авторизованного запроса к серверу ресурсов, даже если он размещён вместе с сервером авторизации. Похожий вид двух строк не делает одинаковыми проверяющего, URI, область действия или допустимый эффект.

Окончание взаимодействия также не завершает решение автоматически. После него сервер авторизации возвращает запрос в обработку и заново оценивает весь контекст — и при согласии, и при отказе владельца ресурса. Только одобренный запрос может вернуть API token или сведения о субъекте. Finalized-запрос уже не выпускает новые токены, не возвращает сведения и не возобновляет взаимодействие; для будущего доступа нужен новый запрос.

Управление токеном — третья поверхность. API token может содержать отдельные URI и учётные данные управления для ротации или отзыва. Ротация сохраняет права и свойства исходного токена; она их не расширяет. Для иных прав требуется обновление через продолжение и новая оценка либо новый запрос. Непрерывность администрирования не равна расширению полномочий.

У сервера ресурсов остаётся собственная точка проверки. GNAP API token предъявляется с предписанным доказательством ключа, а сервер может оспорить запрос без токена или с недействительным токеном. Но и это не доказывает, что деловая цель всё ещё актуальна, что текущие условия позволяют действие или что требуемый эффект наступил.

Надёжная цепочка доказательств хранит раздельно: идентификатор запроса и требуемый доступ, состояние ожидания, URI и доказательство продолжения, результат взаимодействия, повторную оценку, область выданного API token, проверку сервером ресурсов, приём запроса и наблюдаемый эффект. Сведение всего к слову «авторизовано» стирает границы ответственности, которые протокол намеренно сохраняет.

Источники