Аутентификация и авторизация в проекте с микросервисной архитектурой: стратегии, практический пример

Spectr — команда разработки цифровых сервисов

Подписаться 916

Просмотров 13 тыс.

50% 1

«Аутентификация и авторизация в проекте с микросервисной архитектурой: стратегии и практический пример реализации» - Олег Казаков, технический директор, Digital Spectr.
Доклад с митапа #DevTalks ({Perm} Dev Meetup) (11 декабря 2021)
0:00 - Представление спикера
1:30 - История развития веб-разработки
1:57 - Обзор монолитной архитектуры
6:40 - Обзор SPA-решений
8:58 - Обзор микросервисной архитектуры
15:28 - Описание проблемы
18:20 - Аутентификация на каждом микросервисе
20:20 - Работа с пользователями в отдельном микросервисе
23:27 - Паттерн API Gateway
26:04 - Процесс аутентификации
26:52 - Процесс авторизации
29:10 - Описание JWT
31:34 - Описание OAuth 2.0
32:52 - Пример реализации API Gateway
35:00 - Блок вопросов
У микросервисной архитектуры много преимуществ: гибкость и автономность, возможность выбора стека для каждого микросервиса, простота кода и небольшое кол-во зависимостей в рамках одного микросервиса, масштабируемость под нагрузки.
Однако есть и минусы. С развитием любого проекта неизбежно растет и сложность его поддержки.
Рассмотрим один из показательных кейсов: аутентификация пользователей. Сложность в том, что у каждого микросервиса часто есть изолированная БД, но при этом нам необходимо разграничивать доступ в рамках всей системы. Будет разобран практический опыт реализации данного функционала.
Будет полезно:
- тем, кто только начинает знакомство с микросервисной архитектурой
- тем, кто уже столкнулся с проблемами данной архитектуры на своем проекте
В докладе:
- рассмотрен паттерн API Gateway: обзор, конфигурация nginx
- поговориили об OAuth2
- рассмотрены возможные стратегии для реализации аутентификации и практический пример одной из них
Материалы доклада:
- gitlab.com/users/ok-digital-s... - пример реализации
- microservices.io/ - большой портал с информацией про MSA
- www.nginx.com/resources/libra... - книга про микросвервисы от Nginx
- mcs.mail.ru/blog/26-osnovnyh-... - описание различных паттернов MSA
- tsh.io/blog/microservices-arc... - блог про веб-разработку, а данная статья - компиляция нескольких других статей про MSA
- microarch.ru/blog - блог автора курса по микросервисной архитектуре. Статей немного, но надеюсь будут добавляться
#devtalks #devtalks_russia

Опубликовано:

19 июн 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 18

@user-ko3vx6rh6t 2 года назад

Хорошее видео, очень помогло! :)

@indigoram89 3 месяца назад

монолит нормальная тема, если правильно готовить

@molotok1726 10 месяцев назад

Докладчик говорит о том что в монолите все в куче: и бизнес-логика и работа с бд.... по-моему дело не в монолите как архитектуре а в криворукости разработчиков которые не владеют паттернами проектирования. Монолит можно разбить на слабосвязные модули, каждый из которых будет отвечать за одну определенную задачу. Также не понял при чем тут jquery? это просто фреймворк, один из многих, когда он был актуален его можно было грамотно использовать...

@rukurokami 26 дней назад

Это уже будет не монолит а модульная архитектура.

@molotok1726 26 дней назад

@@rukurokami вы путаете архитектуру приложения (монолит/микросервисы) с архитектурой (принципом) написания кода. Монолит может быть построен с использованием модульного принципа точно также как и микросервисы.

@rukurokami 26 дней назад

@@molotok1726 да, вы правы, путаю.

@povauto3298 2 месяца назад

Что-то не понятное... Почему сравнивается вообще SPA, Монолит и Микросервисы? Как сюда попал SPA? SPA - это про реализацию фронта через псевдо-одностраничку. Микросервисы и Монолит - это про всё же бэкенд в первую очередь. Ну то есть можно сделать SPA в виде монолита, а можно за SPA скрыть микросервисы, можно SPA + SOA/SBA. Такое ощущение что когда человек готовился, он перепутал SPA и SOA, а потом его не смутило, что это вообще вещи разных плоскостей и он подготовился как смог) И с чего вдруг SPA - разделение на фронтенд и бэкенд?) В чем изоляция? Можно сделать SPA одним фуллстеком, который всё сделает в одной репе..

@indigoram89 3 месяца назад

php, laravel 🔥

@kuramorireika4135 Год назад

Доклад о базовых вещах для самых маленьких.

@user-qo5ek5tj3b 10 месяцев назад

Тест

@rubyxanax4239 Год назад

Слабый доклад, докладчик видит в способе авторизации через зашивания ролей в пейлоуд jwt и проверку этих ролей уже на самих сервисах какую то панацею, но тут есть один не очень приятный момент. Если наши сервисы используют различные стеки технологий (вплоть до языков), то тогда эту логику проверки ролей нужно будет писать под каждый язык, что на мой взгляд в определенных ситуциях может быть оверинжинирингом. Предложенный способ хорош, если сервисы используют общий стек технологий и мы можем просто как говорится в *** не дуя вынести общую логику проверки пермишенов в отдельную либу и переиспользовать ее где надо. Если же стеки сервисов сильно отличаются, я не вижу проблемы в дополнительном запросе на авторизацию в сервис auth - да, летентность увеличится, но зато нам не придется плодить повторяющуюся логику в каждом сервисе, + у нас появится полноценное использование Single Responsibility и Single Source Of Truth.

@anatoly-k Год назад

этим грешит наверное вся заказная разработка

@Tiber-Lex 11 месяцев назад

Скажите пожалуйста, когда вы говорите про дополнительный запрос к auth, вы про вот эту схему говорите - 27:40 ? Я только начинаю изучать что-то про микросервисы и не до конца понимаю, как это работает, особенно в практическом плане. Верно ли я понимаю эту схему: 1) юзер запрашивает какой-то урл, приложив токен авторизации 2) API Getway как-то определяет, что этот урл требует авторизации и посылает запрос в auth сервис, передавая туда токен 3) Auth сервис по своей базе данных проверяет, что такой токен есть и он живой, отдает положительный ответ (т.е. в auth сервисе есть какая-то таблица с токенами) 4) API Getway получив положительный ответ, еще раз как-то отправляет запрос, но теперь уже на требуемый сервис 5) Требуемый сервис, получив запрос, извлекает из него токен и делает запрос на Auth, с целью убедится, что юзер, владеющий этим токеном, имеет право пользоваться этим сервисом 6) Auth сервис по токену ищет юзера в своей базе данных, а затем проверяет его права (т.е. в auth сервисе так же есть какая-то таблица с правами каждого юзера) и по результатам проверки выдает ответ 7) Конечный сервис, на основе ответа от запроса к Auth сервису выполняет или не выполняет запрошенную операцию.

@raerayan 5 дней назад

Сделай лучше доклад, послушаем тебя. В твоем случае, доп запрос это минус, для каждого проекта нужно выбрать наиболее подходящую архитектуру, выделить преимущества и минимизировать недостатки. Он просто рассказал про архитектуру которая работает в его случае наилучшим образом. А вообще я не вижу существенного минуса реализации авторизации на каждом микросервисе даже при том, что каждый микросервис будет написан на разных языках или технологиях. Логика скорее не будет повторяться, а наоборот инкапсулироваться в каждый микросервис (см. Bounded Context) и команда сама решает какую логику описывать для доступа к тем или иным данным этого микросервиса так как у каждого сервиса она скорее будет своя чем общая для всех, а в твоем случае ты перегрузишь gateway или auth сервис логикой присущей для каждого отдельного сервиса и более того добавишь отдельный запрос. В твоем случе кто будет описывать логику авторизации в gateway или auth? Туда будет лазить каждая команда и писать что-то свое для своего сервиса?

@rubyxanax4239 5 дней назад

@@raerayan Привет! Спасибо за ответ. С момента написания моего комментария прошло больше года, я существенно переосмыслил свой подход. Я согласен, что любая архитектура это свод каких-то компромиссов, которые должны минимизировать проблемы сопровождаемости кода при масштабировании кодовой базы. Я согласен, что докладчик описал решение их собственной проблемы, исходя из их собственного контекста. Также я согласен в важности соблюдение границ ограниченного контекста и согласованности единого языка внутри него. Перенос логики авторизации всех ограниченных контекстов в одно место приведет к разрушению свойств самого ограниченного контекста: 1) Границ владения. Теперь ограниченном контекстом владеет не только команда разработки, но и инфраструктурная команда, отвечающая за общий сервис авторизации. Это потенциально приводит к разрушению доменной модели, что ведет к ухудшению сопровождаемости кода, что ведет к к увеличению TTM, что ведет к потере конкурентных преимуществ, что ведет к гибели проекта. 2) Физические границы. Ограниченный контекст теряет свои физические границы в виде одного независимого разворачиваемого сервиса. Это уже ведет к ухудшению свойств развертываемости и тестируемости. Поэтому сейчас можно сказать что тут должен быть апдейт под моим изначальным комментом. Если кратко - аутентификация в общем инфраструктурном сервисе, авторизация внутри каждого контекста с учетом всех инвариантов домена.

@raerayan 5 дней назад

@@rubyxanax4239 Привет, круто что можешь признавать ошибки и переосмысливать! 👍