Как реализовать Кросс-серверные запросы на authenticate/authorize (jwt) в микросервисной архитектуре?
Привет!
Нужен совет более опытных, чем я, спецов.
Суть тз: имеется микросервисная арх-ра. Аутентификация принимает base64 encoded email&password, возвращает jwt-токен, авторизация - для всех запросов должна принимать jwt, проверять на валидность, обновлять (дату и роли) и обратно отправлять в хедере. Кроме токена, после авторизации на фронт должны посылаться все данные юзера из бд для обновления стейтов (кроме hashpassword, конечно).
Суть вопроса: как реализовать запросы на такой jwt сервер из других микросервисов? Сам jwt лежит вместе с аккаунтингом (для аккаунтинга использую spring security и фильтр для проверки и обновления токена, ибо все утилиты jwt - в той же аппликации, беру их через autowired). То есть если юзер нажимает на кнопку "добавить коммент" - какой-то микросервис а-ля форум должен сначала отправить токен юзера на проверку, получить обновленный, выполнить сам выбранный метод - и вернуть юзеру обновленный токен (в хедере, наверно) вместе с каким-то респонсом из бд. Просто мне кажется странным на фронте для каждой функции прописывать по два реквеста: как-то сервер должен роутить. Может, фильтром в каждом микросервисе, например... есть идеи?
Неа. Фронт один раз при логине получает jwt-токен, а потом шлёт его в заголовке всем другим микросервисам, пока он не устареет. Никаких двух запросов не нужно.
Да, вы правы, шлет. Но каждый микросервис же должен проверить валидность токена. Например, у юзера давно открыт сайт, пару недель назад успешно залогинился - и страница открыта. Он заходит, нажимает на кнопку , где реквест не связан с аккаунтингом. Например, какой-то форум. Разве при этом не проверяется валидность опять?
Nastya1920, для проверки не нужны запросы. Если токен расшифровывается ключом, значит не поддельный. Если в токене дата устаревания больше текущей, значит не протухший. Вся суть JWT в том, что всё необходимое для его проверки находится в самом токене.
Сергей Горностаев, ага... но как в этом случае хранить ключ для проверки? На сервере было бы ясно (я больше по части бэка, если честно). А вот на фронте. Просто в константах где-то в js-файле? Это безопасно?
Nastya1920, если есть желание проверять токен на фронте, то стоит использовать асимметричное шифрование. Хранить публичный ключ в коде фронта безопасно. Но у нас, например, фронт просто принимает токен от сервиса аутентификации, сохраняет в куку и шлёт в заголовке каждого запроса. А все остальные микросервисы в фильтре проверяют валидность токена.
Сергей Горностаев, о, так это как раз то, что я пытаюсь реализовать) просто если токен не валидный - и фронту вернется ошибка, то как обновить token без ввода логина и пароля? Читаю сейчас о refresh token. Видимо, это единственный вариант?
Средний
