JWT: Почему важна аудитория?

JWT обычно включает в себя заявление о целевой аудитории. Я читал во многих местах (в статьях, примерах кода, самом стандарте), что вы должны проверять, что токен предназначен именно для вас, а не для другой аудитории.

Я достаточно доволен, чтобы это принять. Я не планирую строить ничего, что отправляет JWT не по адресу. Но мне любопытно, почему его важно отклонять.

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

Единственный риск, о котором я могу подумать, это если сервер аутентификации выдает разные значения для одного и того же утверждения для разных аудиторий. За исключением плохого пространства имен, я не могу придумать, почему так может произойти.

Например:

{
  "aud": "foo",
  "roles": ["admin"]
}

Вместо:

{
  "aud": "foo",
  "foo.roles": ["admin"]
}

Возможно, вопрос можно лучше сформулировать как:

Какие плохие вещи могут произойти, если я приму (действующий) JWT токен от другой аудитории?

Я бы сказал, что в определенном смысле вы правы в том, что нет ничего особенного в заявлении о целевой аудитории, что вы не могли бы обработать сами с помощью пространств имен и пользовательских проверок безопасности.

Спецификации JWT указывают, что заявление aud (а также другие зарегистрированные утверждения) являются необязательными, и что потребности приложения должны определять, когда их использовать или не использовать.

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

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

Предположим, я регулярно использую JWT от AUTH SERVER для входа на несколько веб-сайтов, включая A и B. Без заявления aud JWT будут идентичными. Это позволит злонамеренному администратору из A использовать мой JWT для аутентификации на B.

Это тот же ответ, который дал Irfan434, но я хотел бы объяснить это на примере, чтобы помочь понять, как это может пойти действительно плохо.

Представьте, что у вас есть крупный издатель JWT, например, Google.

Теперь представьте, что у вас есть приложение с низкой безопасностью, которое использует этого издателя JWT для пользовательских аккаунтов. Допустим, это мобильное приложение под названием “Earl’s Eats”. Это просто приложение для обзора ресторанов, поэтому безопасность может быть не на первом месте, или, возможно, Эрл злой и решает, что хочет эксплуатировать свою пользовательскую базу. У Эрла есть тысячи JWT. Все они действительны. Все эти пользователи действительно вошли в приложение Эрла.

Однако ваше приложение может быть с более высоким уровнем безопасности/риска/влияния. Возможно, это банковское приложение. В обычных условиях: пользователь входит в систему, Google выдает JWT, вы проверяете JWT, вы знаете, кто этот пользователь, и позволяете ему переводить деньги. Если же злой Эрл начинает отправлять вам запросы с JWT, которые он накопил от своих пользователей, вы не заметите этого, если не проверяете aud.

Если вы используете крупного публичного издателя, такого как Google, это огромная проблема. Если вы используете внутреннего издателя JWT, проблема менее серьезная, но она по-прежнему открывает вам доступ к атакам с передачей учетных данных.

Кратко

Если вы проверяете aud, JWT говорит “Это Элис”

Если вы не проверяете aud, JWT говорит “Это Элис, или кто-то, кому Элис доверяет, или кто-то, кому доверяет этот человек, или кто-то, кому они доверяют…”

Это аналогия, которую я использовал, чтобы объяснить использование JWT Google коллеге. Наша система принимает JWT (идентификационные токены) от Google для использования наших API, и у нас есть множество проектов Google Cloud. Заявление aud будет таким же, как имя проекта, например, xyz.apps.googleusercontent.com.

• Google – наш продавец/распределитель билетов.
• Наш API сервер – телохранитель мероприятия.
• Ваш JWT – это билет на мероприятие.
• На вашем билете есть заявление, которое говорит “это для мероприятия A” (заявление aud).

Вот как это разворачивается:

• Мы говорим телохранителю: наши мероприятия – “A” и “B”, и никто другой.
• Законный пользователь, Алиса, идет в Google, чтобы получить билет. Google выдает билет с подписью, которую мы можем проверить. На билете написано “для мероприятия A”.
• Алиса передает этот билет нашему телохранителю, и телохранитель пускает ее внутрь, потому что подпись на билете совпадает, и заявление aud соответствует тому, что мы сказали телохранителю.
• Злонамеренный пользователь, Боб, идет в Google, создает мероприятие “Зло” и получает билет на это мероприятие. Хотя билет действителен (выдан Google), на нем написано “для мероприятия Зло”.
• Боб передает этот билет нашему телохранителю, который проверяет подпись и издателя (iss). Все проверяется, потому что билет законный от Google.
• Если ваша система не проверяет заявление aud, телохранитель бы пустил его внутрь.
• Однако правильный телохранитель проверяет, на какое мероприятие предназначен билет, и в этом случае выгоняет Боба, потому что билет не для мероприятий A или B.

Надеюсь, это поможет!