Передача идентификатора пользователя и авторизации между микросервисами

Question

Я в замешательстве - какой лучший способ передать идентификацию пользователя (информацию об авторизации) между микросервисами асинхронным способом?

Допустим, у меня уже есть точка входа (шлюз API), которая передает аутентификацию и выдает токены JWT.Затем пользователь вызывает некоторую конечную точку API с этим токеном.До этого момента все понятно.Теперь - эта конечная точка должна общаться с другим микросервисом.Этот микросервис должен получать информацию об авторизации (роли и т. Д.).Кроме того - этот канал асинхронный (JMS / Kafka), что означает, что обработка может быть отложена ...

Я также думал о другом случае: у нас есть два сервиса A и B. Оба предоставляют API, к которому можно получить доступвнешним пользователем (аутентификация токена JWT), но они также должны взаимодействовать асинхронно (JMS).Им обоим нужен контекст идентификации пользователя.Опять же - как это передать?

Я могу:

1. передать токен JWT вместе с сообщением в очереди - это безопасно?Что делать, если токены истекают до того, как целевая служба начинает обрабатывать?
2. преобразовывать информацию из токена JWT и передавать ее в виде заголовков HTTP - что, если целевая служба возвращает информацию - мне нужно восстановить контекст авторизации из этого ответа (он должен все еще обрабатыватьсяв контексте конкретного пользователя), но это заставляет меня обрабатывать два типа авторизации: JWT и тот, который возвращен из асинхронного процесса ...
3. ...?

все ониесть минусы для меня, и я не могу найти универсальное решение ...

- Правка

Рассмотрим случай: есть сервис по каталогу продукции и сервис заказа.Оба предоставляют публичный API.Пользователь размещает заказ, он ставится в очередь на обработку.Первый шаг - убедиться, что товары в порядке, и пользователю разрешено их заказывать.Обработка может вызвать службу каталога товаров, но должна передать контекст пользователя.Это та часть, о которой я говорю.

Answer 1

У вас есть

1. Шлюз -> MS1 -> Kafka -> Kafka Consumer -> MS2
2. Шлюз -> MS2

Во второмВ этом случае MS2 действует от имени пользователя, и поэтому здесь имеет смысл JWT пользователя.

В первом случае Kafka Consumer просто синхронизирует действия, которые уже имели место в MS1.Он не действует от имени внешнего пользователя.Внешний пользователь не имеет здесь никакого контроля.Пользователь не может читать или писать что-то не так на этом этапе.Взаимодействие с пользователем заканчивается в самой MS1.

Таким образом, JWT внешнего пользователя не требуется в Kafka Consumer для авторизации.Тем не менее, в сообщении вы можете передать пользовательский контекст, такой как имя пользователя и другие соответствующие детали для обработки.Основываясь на этой информации, вам нужно решить, будете ли вы выполнять заказ или нет.

Потребителю Kafka, однако, потребуются собственные токены доступа, которые будут использоваться во всех различных пользовательских заказах.Тип гранта OAuth 2.0, который вам необходимо использовать здесь для связи между потребителем Kafka и MS2, называется «Учетные данные клиента» тип гранта.

Здесь Потребитель будет напрямую связываться с Авторизациейсервер с соответствующими учетными данными и идентификатором клиента для получения токена доступа