Аутентификация в AIOps реализована как распределенная система из нескольких микросервисов, каждый из которых отвечает за свою часть процесса. Используется JWT-based authentication с разделением на access и refresh токены.
Архитектура аутентификации
JWT Validation] end subgraph "Auth Platform" Identity[Identity Service
Users & Status] Credential[Credential Service
Password Verification] Auth[Auth Service
Session Management] Token[Session Token service
JWT Generation] end subgraph "Data Layer" RedisSession[(Redis
Sessions)] PostgresIdentity[(PostgreSQL
Users)] PostgresCredential[(PostgreSQL
Passwords)] end WebApp -->|1. POST /auth/login| Envoy Envoy -->|2. GetUserByUsername| Identity Identity --> PostgresIdentity Envoy -->|3. VerifyPassword| Credential Credential --> PostgresCredential Envoy -->|4. CreateSession| Auth Auth --> RedisSession Auth -->|5. GenerateTokens| Token Token -->|6. access + refresh| Envoy Envoy -->|7. access, refresh tokens| WebApp WebApp -->|8. API request + JWT| Envoy Envoy -->|9. Validate JWT| Envoy Envoy -->|10. Forward with user_id| Identity style Envoy fill:#4A90E2 style Auth fill:#51B749 style Token fill:#FFA500
Компоненты системы
1. Identity Service
Ответственность: Source of truth для пользователей и их статуса.
API:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
Логика: - Проверяет существование пользователя по username - Возвращает статус (active, disabled, deleted) - Блокирует аутентификацию для неактивных пользователей
2. Credential Service
Ответственность: Безопасное хранение и верификация паролей.
API:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Защита:
Argon2id хеширование:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | |
Защита от DDoS: - Semaphore ограничивает конкурентные операции хеширования - Максимум 10 одновременных hash операций - Защита CPU от перегрузки при атаке
Constant-time verification: - Всегда выполняет полную верификацию, даже если пользователь не существует - Защита от timing attacks - Защита от user enumeration
3. Auth Service
Ответственность: Управление сессиями пользователей.
Session Model:
1 2 3 4 5 6 7 8 9 | |
Хранение: Redis с TTL
API:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | |
4. Session Token service
Ответственность: Генерация и валидация JWT токенов.
Token Structure:
Access Token (short-lived, 15 минут):
1 2 3 4 5 6 7 8 | |
Refresh Token (long-lived, 30 дней):
1 2 3 4 5 6 7 | |
Key Management: - RS256 (RSA with SHA-256) - Периодическая ротация ключей - Старые ключи хранятся для валидации существующих токенов
5. API Gateway (Envoy)
Ответственность: Валидация JWT и маршрутизация запросов.
JWT Validation:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Flow:
1. Envoy извлекает JWT из Authorization: Bearer <token>
2. Валидирует подпись через JWKS endpoint Session Token service
3. Проверяет exp, iss, aud
4. Извлекает user_id и добавляет в заголовок x-user-id
5. Форвардит запрос к целевому сервису
Процесс аутентификации
Login Flow
Authenticated Request Flow
Token Refresh Flow
Logout Flow
Безопасность
Защита от атак
Timing Attacks:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Brute Force Protection: - Rate limiting на API Gateway (по IP, по username) - Account lockout после N неудачных попыток - Exponential backoff
Session Security: - Refresh token rotation (при каждом refresh выдается новый) - Session binding к IP/User-Agent (опционально) - Automatic session revocation при suspicious activity
Password Requirements
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
Связанные страницы
- Authorization — права доступа и RBAC
- Secrets Management — управление секретами
- API Design Principles — REST API guidelines
- Identity Domain — доменная модель Identity