Авторизация и аутентификация в микросервисной архитектуре // Курс «Microservice Architecture»

• Приветствие участников открытого урока по микросервисной архитектуре.  

• Представление Сергея Кривоноса, архитектора решений с 16-летним опытом.  

• Тема урока: аутентификация и авторизация в микросервисах.  

• Знакомство с участниками и компанией "Лотос".  

• Обсуждение паттернов аутентификации и авторизации в монолитах.  

• Обзор подходов к аутентификации и авторизации в микросервисах.  

• Обзор курса и его программы.  

• Активное участие и вопросы в чате.  

• Ответы на вопросы в блоке вопросов и ответов.  

• Важность активного участия и вопросов по теме.  

• Специализация компании на ИТ-обучении.  

• Образовательные лицензии и сертификаты.  

• Разнообразие курсов для специалистов разного уровня.  

• Практический опыт преподавателей.  

• Различие между идентификацией, аутентификацией и авторизацией.  

• Примеры использования терминов в повседневной жизни.  

• Примеры процессов идентификации, аутентификации и авторизации.  

• Регистрация новых пользователей.  

• Управление данными пользователей.  

• Сессионная идентификация и авторизация.  

• Использование различных паттернов для реализации этих процессов.  

• Рассматриваем монолиты для понимания текущих возможностей и их трансформации в микросервисы.  

• Процесс регистрации пользователя: ввод данных, создание записи в базе данных.  

• Процесс аутентификации по логину и паролю.  

• Создание сессии и отправка сессионной куки в браузер.  

• Проверка сессии при каждом запросе и удаление сессии при выходе пользователя.  

• Проверка сессии по идентификатору в заголовках запросов.  

• Передача информации о пользователе в контроллер для обработки бизнес-логики.  

• Возможность использования различных баз данных в зависимости от задач.  

• Пароли не должны храниться в открытом виде, только хэш с солью.  

• Использование современных безопасных алгоритмов, таких как bcrypt.  

• Обязательное использование защищенных соединений по HTTPS.  

• Сессии хранятся в куки, но не должны содержать конфиденциальные данные.  

• Использование случайно длинных ключей и флагов для повышения безопасности.  

• Куки должны передаваться только по HTTPS и быть привязаны к определенному домену.  

• Обсуждение использования сессий и их хранения.  

• Сессии обычно хранятся в базе данных или кэше, а не в памяти сервера.  

• Конфиденциальные данные не должны храниться в сессиях, чтобы избежать утечек.  

• IDP позволяет пользователям регистрироваться и аутентифицироваться через внешние сервисы.  

• Это решает проблему запоминания множества логинов и паролей.  

• Внешний IDP берет на себя ответственность за идентификацию и аутентификацию.  

• Примеры IDP: Google, GitHub, Яндекс.  

• Пользователи могут использовать одну учетную запись для аутентификации на разных сайтах.  

• Google обеспечивает безопасное хранение и аутентификацию пользователей.  

• Существует де-факто стандарт для идентификации: OAuth 2.0.  

• Устаревший протокол SAML практически не используется.  

• Можно использовать самописные решения, но это сложно и долго.  

• В корпоративных системах часто используются внутренние IDP.  

• Пример: KeeLoq.  

• Выбор IDP зависит от опыта команды и требований организации.  

• OAuth 2.0 был фреймворком для идентификации и авторизации.  

• Проблема: отсутствие стандартизации до получения информации пользователя.  

• Решение: стандарт OpenID Connect, который стандартизирует процесс.  

• Приложение должно быть зарегистрировано у IDP.  

• Процесс включает генерацию пары ключ-значение и настройку конфигураций.  

• Пользователь проходит аутентификацию через IDP, который возвращает токены.  

• Пользователь заходит на сайт, и логин контроллер перенаправляет запрос на IDP.  

• IDP возвращает информацию о пользователе и токены.  

• Приложение использует токены для дальнейших запросов.  

• Токены: access, refresh, id.  

• access token используется для отправки запросов от имени пользователя.  

• refresh token обновляется автоматически, если срок действия access token истек.  

• Протокол OAuth 2.0 широко используется и не требует написания собственных решений.  

• Процесс аутентификации повторяется для каждой сессии.  

• IDP обеспечивает безопасность и удобство для пользователей.  

• Использование библиотек для разных языков программирования повышает конверсию и лояльность пользователей.  

• Это позволяет быстрее выводить бизнес-сервисы на рынок и снижает необходимость придумывать пароли.  

• В корпоративных сервисах можно использовать локальные анти-провайдеры для решения проблем.  

• СС.РФ уязвимость позволяет злоумышленнику подделать ссылку и использовать сессию пользователя.  

• Для защиты используются CSRF-токены, которые генерируются сервером и передаются в cookie.  

• Современные фреймворки обычно реализуют проверку CSRF-токенов, но важно проверять документацию и проводить пентесты.  

• Рекомендуется разделять данные пользователей и сессии.  

• Сессии могут храниться в одном репозитории, а данные пользователей — в другом.  

• Это позволяет лучше защитить данные и избежать ошибок.  

• Иденти-провайдеры проверяют данные пользователя и аутентифицируют его.  

• Авторизация — это проверка прав доступа, которая происходит на внешнем провайдере.  

• Важно различать идентификацию и авторизацию, чтобы избежать ошибок.  

• В микросервисах аутентификация выносится в отдельный сервис.  

• Это позволяет масштабировать и управлять нагрузкой на сервис аутентификации.  

• Существуют три подхода к реализации аутентификации в микросервисах: хранение сессий в базе данных, создание сервиса на базе данных и использование прокси.  

• Прокси-подход позволяет отвязать микросервисы от сервиса сессий.  

• Каждый микросервис занимается только своей бизнес-логикой, а аутентификация передается прокси.  

• Пример реализации: Nginx с HAProxy, который проверяет сессию и отправляет пользователя на аутентификацию при необходимости.  

• Иденти-провайдеры могут быть реализованы как фасад для клиента.  

• Это позволяет использовать различные протоколы и хранилища пользователей.  

• Пример: проект Dex на GitHub, который является адаптером для различных протоколов.  

• Горизонтальное масштабирование баз данных легко решается.  

• Для фронтенда обычно ничего делать не нужно, все поддерживается браузерами.  

• На бэкенде нужно реализовать хранилище сессий.  

• Идентификация: указание данных, таких как логин или биометрия.  

• Аутентификация: подтверждение личности через логин или код из SMS или email.  

• Авторизация: проверка прав пользователя на выполнение действий.  

• Авторизация проходит на бэкенде, так как это бизнес-логика.  

• Иденти-провайдер занимается только идентификацией.  

• Вопрос о выборе между использованием существующего провайдера или созданием собственного.  

• Если у компании есть опыт и другие приложения, лучше использовать существующий провайдер.  

• KeeLoq популярен и поддерживается, имеет открытый исходный код.  

• Важно использовать защищенные соединения для передачи данных.  

• Для стартапов лучше использовать существующие провайдеры, такие как Google или Яндекс.  

• Использование куки для аутентификации небезопасно.  

• Рекомендуется использовать защищенные соединения и проверять уязвимости.  

• Токен-базированные сессии генерируют уникальный токен вместо идентификатора сессии.  

• Валидация токена может происходить через внешний провайдер или локально.  

• Локальная проверка может быть быстрее, но увеличивает риски компрометации токена.  

• JSON Web Token JWT - единый стандарт для токенов.  

• Состоит из заголовка, данных и подписи.  

• Заголовок содержит алгоритм подписи, данные - информацию о пользователе, подпись - подтверждение подлинности.  

• Подпись используется для проверки изменений данных.  

• Закрытый ключ хранится на сервере и недоступен для внешнего мира.  

• JWT не шифруется, но может быть зашифрован для дополнительной безопасности.  

• В теле JWT можно добавлять атрибуты, такие как кто выпустил, кому выпустил.  

• Можно создавать свои атрибуты для бизнес-требований.  

• JWT не рекомендуется использовать для хранения ценной информации.  

• Пользователь логинится, получает JWT и сохраняет его на клиенте.  

• JWT используется для реализации Single Sign-On SSO.  

• JWT имеет ограниченный срок жизни, что требует автоматического обновления.  

• JWT обычно хранятся в куках или памяти.  

• Хранение в Local Storage не рекомендуется из-за уязвимостей.  

• Хранение в куках ограничено по размеру, что может быть проблемой для больших JWT.  

• Не рекомендуется хранить JWT в Local Storage.  

• Хранение в памяти неудобно из-за ограничений между вкладками.  

• Хранение в куках остается предпочтительным, но имеет свои ограничения.  

• Для валидации JWT существуют готовые библиотеки.  

• Использование JWT упрощает разработку бэкенда, но усложняет фронтенд.  

• Проблемы с хранением JWT в куках могут возникать в разных браузерах.  

• JWT не использует симметричное шифрование из-за открытого ключа на сервере.  

• Хранение JWT в куках может быть проблематичным в некоторых браузерах.  

• В больших организациях хранение JWT в куках может быть запрещено из-за безопасности.  

• В системе есть микросервисы, которые взаимодействуют друг с другом.  

• Рекомендуется выставлять сервисные API на отдельном контексте.  

• Клиентские API выставляются на отдельном фасаде.  

• Не рекомендуется передавать сессию пользователя между микросервисами.  

• Каждый микросервис должен иметь свою систему аутентификации.  

• Возможны два подхода: передача идентификатора в заголовках или использование токенов.  

• Передача идентификатора в заголовках может быть подделана.  

• В Kubernetes можно настроить правила для доступа между сервисами.  

• Рекомендуется использовать токены для аутентификации.  

• В Kubernetes используется сервис-мэш для генерации и проверки токенов.  

• Администраторы могут настраивать доступы и сетевые правила.  

• Сложность аутентификации переносится на уровень выше.  

• Basic Auth может быть приемлемой практикой при согласовании с командой.  

• В некоторых случаях Basic Auth может быть единственным вариантом.  

• Важно объяснить команде, почему Basic Auth используется.  

• Логины и пароли не должны храниться в открытом виде.  

• Рекомендуется использовать хранилище конфигурации, например, Hashicorp Vault.  

• Шифрование конфигов в Git также может быть вариантом.  

• Sitecar в Kubernetes перехватывает трафик и обрабатывает его.  

• Это прокси-микросервис, который помогает в аутентификации.  

• Рекомендуется использовать Sitecar для авторизации между сервисами.  

• Hashicorp Vault интегрируется с Kubernetes и Gitlab.  

• Можно настраивать конфиги на лету без пересборки сервиса.  

• Конфигурации могут обновляться автоматически через определенные интервалы.  

• Авторизация проверяет права доступа пользователя или приложения.  

• Два подхода: аутентификация и авторизация в микросервисе и централизованный сервис авторизации.  

• В микросервисной архитектуре каждый микросервис проверяет права доступа самостоятельно.  

• Централизованный сервис авторизации проверяет права доступа для всех пользователей.  

• Сервис авторизации проверяет права пользователя и возвращает результат.  

• В зависимости от наличия централизованного сервиса авторизации, можно использовать его или реализовывать локально.  

• В микросервисной архитектуре создается базовый шаблон для быстрого создания микросервисов.  

• Включает интерфейсы, интеграции, мониторинг и обсервабилити.  

• Важно иметь шаблон для быстрого создания и настройки микросервисов.  

• Вебинары проходят два раза в неделю, материалы сохраняются в личном кабинете.  

• Домашние задания можно выполнять в любое время, преподаватели проверяют их оперативно.  

• В чате в Telegram можно задавать вопросы и получать консультации.  

• Курс не дает базовых основ программирования, подразумевается опыт разработки.  

• Программа разделена на пять частей: Docker, Kubernetes, мониторинг, взаимодействие, микросервисы.  

• Включает разделы по распределенным базам данных, шардированию и транзакциям.  

• После прохождения курса можно претендовать на вакансии Java-разработчиков, разработчиков на других языках.  

• Требования вакансий включают понимание проектирования современных систем, микросервисов, REST API, Kafka и других технологий.  

• Курс готовит к собеседованиям и претензиям на вакансии архитекторов и проектировщиков высоконагруженных систем.  

• Обсуждение команды и курса.  

• Использование подхода куки для хранения данных.  

• Рекомендация использовать готовые библиотеки и фреймворки.  

• Старт обучения на курсе 30 июня, следующий открытый урок 31 июля.  

• Призыв пройти опрос в чате.  

• Благодарность за участие и время.  

• Завершение презентации и открытого урока.  

• Подчеркивание полезности вебинаров и обучения.  

• Важность получения новой информации.  

• Благодарность за уделенное время и приглашение на курс.