Как передавать токен авторизации в микросервисах при отсылке сообщения?

Question

[Денис Яковлев]

В микросервисной архитектуре, есть api gateway, авторизационный сервис и бэкенд сервис. Api gateway авторизовал пользователя через авторизационный сервис, получил jwt токены. Далее, в случае http запросов, api gateway отправляет в бэкенд сервис хэдер Authorizaion: Bearer JWT-Token, в котором уже есть identity пользователя. Есть ли устоявшиеся практики, как передавать identity пользователя при передаче сообщений через message queue?

Comments

[Zhainar]

не совсем понял, но просто передавать ид пользователя не подходит?

[Денис Яковлев]

Zhainar, разумеется можно просто полем, можно в хедер засунуть. Я спрашивал про какие-то стандарты. Ну вот как авторизацию по http стандартно передавать в соответствующем хедере. Может и для mq что-то такое есть, какие-то best practices. Я же точно не первый, кто озаботился передачей инфы о пользователе через сообщения

[entermix]

Денис Яковлев, https://github.com/rabbitmq/rabbitmq-auth-backend-...

Возможно это может помочь?

[Денис Яковлев]

entermix, спасибо за интересную ссылку, но это про авторизацию самих сервисов, насколько я понял

Answer 1

[Артём Силантьев]

Передавать заголовок "Authorizaion: Bearer *JWT-Token" в каждом api запросе, это уже и есть одна из устоявшихся практик.

JWT, это зашифрованный сообщение (JSON), в котором содержится userId, благодаря которому бакенд связывает запрос с каким то юзером.

Раньше могли передавать просто какой-то токен, типа sessionid, который указывал на какую то запись в БД для бакенда, где и хранилась информация о юзер айди, но сейчас в основном JWT используют, при этом JWT так же храниться и в БД обычно.

Comments

[Денис Яковлев]

Имеете в виду в сообщение в кафку отправлять такой же хэдер Authorization: Bearer?

[Артём Силантьев]

De1mos, если сервер идентифицирует пользователя через этот заголовок (Authorization:) то да.

Обычно клиент логинеться через пост запрос, например /api/user/login, от него в случаи успеха получает JWT токен, который сохраняет, и в дальнейшем встраивается во все запросы к апи, через заголовок Authorization

[Денис Яковлев]

Артём Силантьев, извините, но вы точно говорите про взаимодействие через message queue (RabbitMQ, Kafka, AMQP и т.д.), а не через http запросы?

[Артём Силантьев]

De1mos, а, вот вы про что... не сразу понял, что дело идёт о MQ системах, стандартов авторизации в таких системах мне не известны, хотя думаю их можно посмотреть в документациях. Так же скажу, что обычно для MQ авторизации не нужно, они просто находятся внутри закрытой сети, как база данных или какой нибудь редис, и те микросервисы, которым необходимо подключиться к MQ, просто берут и подключаются по адресу и порту.

[Денис Яковлев]

Артём Силантьев, про авторизацию да, все верно. Но JWT обычно кроме собственно функции авторизации несет еще в payload хотя бы id пользователя, который совершает запрос. Мне кажется я далеко не первый, кому надо передавать id пользователя в сообщениях

[Артём Силантьев]

Денис Яковлев, вы хотите предавать какой-то id, в тех сообщениях, которые отправляете в MQ? Тут я точно не знаю стандартов и не уверен, что они есть... так как использование MQ, это не на столько часто используемая операция, как авторизация в rest-api. MQ системы используются обычно либо в HighLoad системах, либо под специфические задачи, вы можете сами определить, как вам передавать id в MQ сообщениях... например сделать стандартную обёртку для MQ сообщений, типа JSON:
{
id: "*какой то айди*"
data: { ... то, что передаётся в сообщении ... }
}

[Денис Яковлев]

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

[Артём Силантьев]

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