к api gateway, предоставляя ему ассез токен, далее апи ггетвей делает запрос к авторизационному микросервису и проверяет доступ, после этого подменяет ассезз токен на другой токен с доступом к микросервису и перенаправляет запрос клиента к микросервису, а микросервис снова проверяет токен, обращаясь к авторизационному микросервису. Меня немного смущает в такой архитектуре, что по сути, чтобы получить доступ к микросервису нужно сделать 4 запроса по сети, то есть скорость запроса снижается в 4 раза. кто сталкивался? мои микросервисы будут в инете, а не в приватной сети
чет как-то сложно. какую задачку вы решаете? вы хотите проверять на микросервисе акссесс токен юзера? чтобы знать, кто к вам пришел?
хочу понять как строить защиту при расположенных микросервисах в сети, но при этом при наличии единого апи, чтобы клиент обращался не к разным сайтам, а к одному
Прокси на фронте?
на апи
Адовый оверхед. Я бы сделал так. Бфф для фронта, которых ходит в сервис авторизации, тот проводит аутентификацию, и возвращает юзера и права авторизации. А далее бфф педорит в реестр сервисов, который перенаправляет в нужный сервис. Общение между фронтом и бфф по токе аавторизации. А общение между сервисами по токену из конфига реестра сервисов.
А что такое бфф ?
best friends forever
Где тег? Говорил что амбассадора поставишь
тег не могу сделать, только ро или бан если хочешь)
Я имею ввиду фронт реаерс прокси аля нгинкс, траефик etc.... , а бек микросервисы по роутах
Добро пожаловать kubernets и 99.99
ниасилил
даже добавлю: 42
uptime 99.99% sla. И балансировка сервисов, каждый сервис в 10 экземплярах в своем поде
сказочно
ну я думал сервис делать как nodejs кластер
Вам точно следует почитать про кубер. https://kubernetes.io/ru/
Вот тут и нужен jwt, который можно проверить без дёргания сторонних сервисов
Обсуждают сегодня