Передача декодированной полезной нагрузки JWT в микросервисы

Мы меняем архитектуру аутентификации нашего приложения, чтобы перейти на Json Web Token.

Фактически, входящие запросы сначала проходят через API-шлюз, который отправляет запросы различным микросервисам нашего стека.

Аутентификация и проверка JWT, переданного в каждом запросе, выполняется в шлюзе.

Что бы вы сделали с JWT после аутентификации?

  1. Передать "как есть" последующим микросервисам?
  2. Расшифровать его в шлюзе и передать сервисам только декодированную полезную нагрузку?

Я вижу плюсы и минусы обоих решений:

  1. Pro: мы полностью сохраняем стандартный HTTP-заголовок для аутентификации. Минусы: нам нужно декодировать токен в каждой службе.

  2. Pro: токен уже декодирован и может напрямую использоваться в службах. Минусы: мы должны использовать нестандартный заголовок http для передачи декодированной полезной нагрузки.

Есть ли в этой ситуации какой-нибудь «стандартный» способ?

Каково твое мнение ?

Спасибо !


person Clement    schedule 06.10.2017    source источник
comment
Сохраните JWT в cookie. По умолчанию он передается на сервер в каждом запросе в виде заголовка. Затем вы можете декодировать его в обработчике запросов сервера.   -  person Fawaz    schedule 06.10.2017
comment
Токен будет храниться в файле cookie на стороне клиента (приложение SPA) и передаваться на шлюз API при каждом запросе. Шлюз проверит его и примет / отклонит запрос. Если запрос будет принят, токен будет передан базовым микросервисам. У меня вопрос: после аутентификации я должен передавать токен JWT непосредственно службам или должен передавать только декодированную полезную нагрузку JWT? Я знаю, что оба будут работать, но мне интересно, есть ли какие-нибудь «лучшие практики».   -  person Clement    schedule 06.10.2017


Ответы (1)


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

person Konstantin Gusev    schedule 07.02.2019