Архітектура автентифікації в мікросервісах: гібридний підхід

Вступ У світі мікросервісів проектування надійної системи автентифікації та авторизації є критично важливим для забезпечення безпеки, масштабованості та підтримуваності. Однією з поширених суперечок є питання, де обробляти автентифікацію: в API-шлюзі чи у спеціалізованому Auth-Service. У цій статті ми розглянемо переваги та недоліки обох підходів і продемонструємо, як реалізувати гібридне рішення за допомогою Java Spring Boot.

Виклик: Де повинна знаходитися автентифікація?

При побудові архітектури мікросервісів виникають два основних підходи до автентифікації:

1. Автентифікація в API-шлюзі: Шлюз обробляє перевірку токенів, забезпечуючи політики контролю доступу.
2. Спеціалізований Auth-Service: Окремий сервіс керує автентифікацією користувачів, видачею токенів і авторизацією на основі ролей.

Хоча обидва підходи мають свої переваги, гібридний підхід часто поєднує найкраще з обох світів, забезпечуючи оптимальний баланс безпеки, масштабованості та продуктивності.

Чому гібридний підхід?

Гібридна модель включає:

1. Auth-Service:
2. Керує автентифікацією користувачів і видає токени (наприклад, JWT).
3. Централізує управління користувачами, хешування паролів і політики безпеки.
4. Пропонує гнучкість для впровадження нових механізмів автентифікації (наприклад, OAuth2, OpenID Connect).
5. API-шлюз:
6. Виконує легку перевірку токенів (наприклад, перевірка підпису JWT).
7. Направляє запити до відповідних мікросервісів на основі ролей користувачів або дозволів, вбудованих у токени.

Переваги гібридного підходу:

• Розподіленість відповідальностей: Зберігає логіку маршрутизації та безпеки окремо.
• Масштабованість: Auth-Service масштабуються незалежно від API-шлюзу.
• Продуктивність: Зменшує мережеві виклики, перевіряючи токени локально в шлюзі.
• Гнучкість: Легко розширюється для нових схем автентифікації або зовнішніх постачальників ідентифікації.

Проектування гібридної моделі з Java Spring Boot

Ось як ви можете реалізувати цю архітектуру, використовуючи start.spring.io для створення ваших сервісів.

1. API-шлюз

API-шлюз виступає точкою входу для всіх запитів клієнтів, виконує перевірку токенів і маршрутизує їх до відповідних мікросервісів.

Залежності для API-шлюзу Додайте наступні залежності до вашого проекту API-шлюзу:

• Spring Cloud Gateway: Основна залежність для функціональності API-шлюзу.
• Spring Security: Для локальної перевірки токенів.
• Spring Boot Actuator: Для моніторингу та перевірок стану.
• Eureka Discovery Client (необов'язково): Для динамічного виявлення сервісів.
• Micrometer (необов'язково): Для збору метрик і спостережуваності.

Приклад конфігурації з start.spring.io:

org.springframework.cloud
spring-cloud-starter-gateway

org.springframework.boot
spring-boot-starter-security

org.springframework.boot
spring-boot-starter-actuator

Основні обов'язки API-шлюзу:

1. Маршрутизація: Направлення запитів до відповідних мікросервісів.
2. Перевірка токенів: Локальна перевірка JWT за допомогою підпису і вбудованих заявок.
3. Лімітинг та логування: Забезпечення ефективного керування трафіком.

2.

Auth-Service

Auth-Service відповідає за автентифікацію користувачів, видачу токенів та управління контролем доступу на основі ролей.

Залежності для Auth-Service Додайте наступні залежності до вашого проекту Auth-Service:

• Spring Web: Для створення REST API.
• Spring Security: Для автентифікації та авторизації.
• Spring Data JPA: Для управління даними користувачів.
• Database Driver: Для збереження даних (наприклад, MySQL, PostgreSQL).
• Spring Boot Actuator: Для моніторингу та перевірок стану.
• JWT Library: Для генерування та підписування токенів (наприклад, jjwt).

Приклад конфігурації з start.spring.io:

 org.springframework.boot  
 spring-boot-starter-web  


 org.springframework.boot  
 spring-boot-starter-security  


 org.springframework.boot  
 spring-boot-starter-data-jpa  


 io.jsonwebtoken  
 jjwt  
 0.11.5  


 mysql  
 mysql-connector-java  

Основні обов'язки Auth-Service:

1. Автентифікація користувачів: Перевірка облікових даних та надійне хешування паролів.
2. Видача токенів: Генерація JWT, що містять претензії користувача (наприклад, ролі, дозволи).
3. Управління ролями та дозволами: Централізоване управління політиками доступу.
4. Підтримка зовнішніх постачальників ідентифікації (необов'язково): Інтеграція з постачальниками OAuth2 або OpenID Connect.

Приклад Робочого Процесу

1. Автентифікація користувача:

• Клієнт надсилає облікові дані (наприклад, ім'я користувача та пароль) до Auth-Service.
• Auth-Service перевіряє облікові дані та видає JWT.

2. Перевірка в API-шлюзі:

• Клієнт включає JWT у заголовок Authorization для кожного виклику API.
• API-шлюз перевіряє підпис JWT та перевіряє претензії (наприклад, термін дії, ролі).
• Якщо токен дійсний, запит маршрутується до відповідного мікросервісу.

3. Тонка авторизація:

• Подальші сервіси можуть застосовувати додаткові дозволи на рівні ресурсів, спираючись на претензії JWT.

Висновок

Гібридний підхід до автентифікації в мікросервісах забезпечує баланс між продуктивністю, безпекою та підтримуваністю. Централізуючи автентифікацію в Auth-Service та делегуючи легку перевірку API-шлюзу, ви досягаєте масштабованості та гнучкості без надмірного навантаження на будь-який один компонент.

Використання інструментів, таких як start.spring.io та Java Spring Boot, дозволяє швидко розгорнути ці сервіси з мінімумом шаблонного коду. Незалежно від того, чи будуєте ви новий проект, чи рефакторите моноліт, ця архітектура може адаптуватися до ваших потреб.

Перекладено з: Architecting Authentication in Microservices: A Hybrid Approach