Токены доступа JWT: противоречие?

Question

Я пытаюсь реализовать решение безопасности для архитектуры микросервисов. Мой сервер аутентификации поддерживает OAuth2 и OIDC.

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

• Используйте JWT (ID-токен), который я получаю от сервера авторизации, в качестве токена-носителя при совершении вызовов.
• Каждая служба может проверять этот токен по отношению к JWKS (в кэше) сервера аутентификации, чтобы убедиться, что он действителен
• Каждый сервис может включать токен при вызове других сервисов

Я читал, что нормально, чтобы токен доступа был JWT .

Отлично, но:

Моя (моральная?) Проблема заключается в следующем:

A JWT предназначен для конкретной аудитории . Фактически, в спецификации сказано, что если это не для вас, вы должны отказаться от него.

A Токен на предъявителя равен , предназначенный для не аудитории . Поэтому, если я выдаю токен, который говорит, что предъявитель может читать мою почту, он может пройти через полдюжины различных служб, любая из которых должна иметь возможность читать мою почту.

Итак, мой вопрос прост: как JWT может быть токеном на предъявителя?

Бонусные баллы за ссылки на любые интересные статьи / видео / примеры эффективного решения распределенной аутентификации!

Answer 1

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

Это относится и к токену на предъявителя.Он может быть передан кем угодно, но только его аудитория должна действовать в соответствии с его действительностью.

Таким образом, сервис X может получить токен-носитель JWT с сервисом целевой аудитории Y. Он не даст вызывающему клиенту никакой авторизации на основена что, но вызов службы Y при этом не нарушает притязаний аудитории.Что может нарушить утверждение аудитории, так это если служба X проверит JWT, увидит несоответствующую аудиторию и скажет: «Ну, поскольку у клиента есть JWT, в котором указано, что это пользователь Fubar, я могу вернуть некоторую информацию о пользователе Fubar».

Разница для непрозрачного токена-носителя не-JWT заключается в том, что служба X не сможет использовать его неправильно ...