Сервис получает подписанный JWT, выпущенный доверенным центром для другого сервиса. Какая проверка не позволит принять такой токен?
Сервис должен проверить аудиторию токена — claim aud — и убедиться, что в нём указан именно этот сервис. Валидная подпись доказывает только выпуск токена доверенным центром, но не предназначение токена для конкретного получателя.
В распределённых системах один центр выдачи токенов часто обслуживает множество сервисов. Поэтому одной проверки подписи недостаточно: любой сервис, доверяющий этому центру, потенциально может принять токен, выпущенный для другого сервиса.
Claim audience появился как способ явно связать токен с предполагаемым получателем. Это ограничивает повторное использование корректно подписанного токена за пределами его исходного назначения.
Предположим, токен выпущен для сервиса профилей, но его предъявляют сервису платежей. Если платежный сервис проверяет только подпись, срок действия и, возможно, издателя, он может ошибочно принять чужой токен.
Так возникает подмена назначения токена: компрометация или ошибка в одном клиенте расширяет область применения токена на другие сервисы. Последствия зависят от полномочий, но могут включать несанкционированное чтение данных или выполнение операций от имени субъекта токена.
При обработке токена сервис должен проверить, что значение aud соответствует его собственному идентификатору. Если токен предназначен для другого сервиса или claim отсутствует там, где он обязателен по принятому контракту, запрос следует отклонить.
Проверка аудитории дополняет, а не заменяет другие проверки: подписи, доверенного издателя, срока действия, времени начала действия и необходимых полномочий. После успешной аутентификации токена сервис всё равно должен отдельно проверить, разрешено ли субъекту выполнять конкретную операцию.
Проверка aud защищает границу между сервисами, но не делает токен неперехватываемым. Она не предотвращает использование токена самим предназначенным сервисом до истечения срока действия и не заменяет защиту канала, безопасное хранение токенов, отзыв или короткое время жизни.
В системах с несколькими допустимыми аудиториями нужно строго определить этот набор и не принимать произвольное совпадение. Также важно согласовать формат идентификатора: различия в URI, регистре, окружении или именовании не должны случайно превращать проверку в слишком широкую.
Компания использует единый центр идентификации для сервисов профиля и платежей. Платежный сервис проверял подпись JWT и срок действия, но не проверял aud; поэтому токен, выданный клиенту профиля, принимался платежным API.
Рассматривались три варианта. Раздельные ключи для каждого сервиса уменьшили бы область доверия, но усложнили ротацию и управление ключами. Проверка только ролей или scopes не решала проблему назначения: одинаковое полномочие могло быть интерпретировано разными сервисами. Полагаться на шлюз было проще, но оставляло риск при прямом доступе к сервису или ошибке маршрутизации.
Выбрали обязательную проверку aud на каждом сервисе, дополнив её проверкой издателя, подписи, времени жизни и полномочий. В результате токены для профиля перестали приниматься платежным API, а авторизация конкретных операций осталась отдельным слоем.
Достаточно ли проверять только aud, если подпись токена корректна?
Нет. aud — это утверждение внутри токена, а не доказательство его подлинности. Сначала нужно убедиться, что токен подписан доверенным ключом и выпущен допустимым издателем, затем проверить его время действия, аудиторию и полномочия.
Чем проверка аудитории отличается от проверки scopes?
aud отвечает на вопрос, какому сервису предназначен токен. Scope отвечает на вопрос, какие действия или ресурсы доступны субъекту. Токен может быть предназначен правильному сервису, но не иметь нужного scope; и наоборот, наличие подходящего scope не делает токен предназначенным для данного сервиса.
Следует ли принимать токен, если его aud содержит несколько сервисов?
Только если такая модель явно предусмотрена контрактом безопасности. Сервис должен проверить, что его идентификатор входит в строго определённый список допустимых аудиторий, а не принимать любой токен от доверенного издателя. Чем больше аудиторий у одного токена, тем шире последствия его компрометации, поэтому для чувствительных операций предпочтительнее узко предназначенные токены.