Comments 8
Лучшая статья по теме из тех что я видел
А мне нравится эта статья.
По данной теме могу порекомендовать следующую статью: https://cheatsheetseries.owasp.org/cheatsheets/Microservices_security.html (не смотрите, что OWASP, там не только про безопасность)
По моему, чтобы проверить подпись jwt достаточно публичного ключа, в случае асимметричной подписи. Тогда на все сервисах можно хранить только публичный ключ, а не приватный. Если же подпись симметричная, то да везде нужно хранить секретный ключ.
Норм. Сложности появляются когда у вас несколько auth провайдеров и JWT может содержать разные identity.
PS: у нас в качестве api gateway используется простой прокси на node.js, что позволяет более гибко работать с маршрутизацией (в частности, храним маршруты в базе, а не перезаливаем конфиги nginx'a).
Треть статьи - введение в различия между двумя основными архитектурными стилями. Наверное, автор хочет плавно подвести нас к теме статьи? Но нет, в 100501 изложении монолита не видно ни слова про тему статьи. Подразумевается, но не сказано.
Описание AA в каждом пункте. "Мы", "нам" - кто эти загадочные звери?
Что мешает указывать конкретные сущности (группы сущностей), которые выполняют это действие?И самый интересный пункт, OAuth 2.0, внезапно всего три строчки. И это всё?!
Только собрался спросить, раз "через refresh можно", значит, необязательно?, и кто решает, можно или нет и т.п., как статья резко закончилась.
В общем, я не понял ни смысл статьи, ни части её содержания. И даже завидую тем, кому она показалась лучшей
Я думал тут про кейклок будет, даже не упомянули )
Если честно мне кажется что тема не раскрыта. На шлюз тогда ложится много ответственности за взаимодействия между собой сервисов. Если шлюз начнет лажать, то лажанет все.
Шлюз можно использовать для прослойки между клиентом и сервисом. В рамках взаимодействия между сервисами лучше организовывать общение по топологии звезда. Сервис который принял любую заявку от клиента, он должен на нее и ответить и все должно работать в рамках асинхронности. По поводу авторизации/аутентификации. Клиент думаю должен пройти аутентификацию на отдельном сервисе. А на остальных сервисах по токену доступа (свой-чужой) проходит автоматическую авторизацию (Сервисы по токену сами запрашивают у сервиса аутентификации необходимую информацию ). При этом организация ролей доступа к сервисам должна храниться на сервисе аутентификации, а организация клиентских ролей у каждого сервиса свой. Один раз прошел автоматическую авторизацию, и сервис с клиентом работает как с полноценным пользователем. При этом между сервисами устанавливаются доверительные отношения и не проводят дополнительную авторизацию клиента на своих сервисах если запрос по токену доступа пришел от сервиса.
Каждый микросервис будет заботиться за свое состояние в отношении клиента сам. При этом сервис будучи самостоятельной единицей, легко интегрировать в общую систему микросервисов. Т.е. вы пишите микросервис со своей аутентификацией и авторизацией и необходимыми ролями. Потом заменяете авторизацию клиента, на доступ к автоматической авторизации.
Вам лишь остается выбрать способ взаимодействия и проведения транзакций чтобы было без проблем интегрировать микросервис в общую систему взаимодействия.
Также сервисы нужно разделять на служебные и публичные. Публичные сервисы взаимодействуют с клиентом, а служебные работают на нужды системы.
Аутентификация и авторизация в проекте с микросервисной архитектурой: стратегии, практический пример