Как видно из названия, я ищу решение, которое обеспечивало бы обмен данными между нашими внутренними микросервисами.
Конечной целью является защита связи путем сохранения заголовков запросов в качестве утверждений в JWT для предотвращения спуфинга. Сначала я хотел, чтобы наш шлюз создавал, управлял и подписывал (с какой-то политикой кэширования) все внутренние токены, которые будут использоваться для передачи обратно и четвертого между сервисами. Каждая служба будет отвечать за проверку входящего запроса с использованием общего секрета.
Проблема здесь в том, что некоторые из наших сервисов требуют обновления HttpContext новыми значениями x-заголовка (например, один случай использования был бы при необходимости обхода authz). Таким образом, для этих служб единственный способ обойти это - создать / подписать новый токен с обновленными утверждениями в Сервисе A, прежде чем отправить запрос в Сервис B.
Я действительно стараюсь избегать смешивания всей этой дополнительной логики обработки для управления токенами на уровне обслуживания, который уже является четко определенной архитектурой микросервисов. Кэширование токенов - это вариант, который в данной модели может помочь с производительностью, но с точки зрения общего дизайна, есть ли лучший подход? Может быть, кроме использования JWT для внутреннего authn?