Сервер аутентификации/авторизации

Взаимодействие сервера аутентификации с основным api сервером

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

Использование токенов (JWT, OAuth2)

Один из наиболее популярных подходов — использование токенов (например, JWT — JSON Web Tokens) для аутентификации и авторизации.

Шаги взаимодействия:

1. Аутентификация пользователя:
   • Клиент отправляет логин и пароль на сервер аутентификации.
   • Сервер проверяет данные и, в случае успешной аутентификации, генерирует токен доступа (например, JWT) и возвращает его клиенту.
2. Использование токена для доступа к основному API:
   • Клиент передает полученный токен в заголовках запроса к основному API серверу.
   • Основной API сервер проверяет токен (например, через библиотеку для валидации JWT).
   • Если токен валидный, запрос обрабатывается, и клиенту возвращаются данные.
3. Валидация токена:
   • Основной API сервер проверяет подпись токена и его срок действия.
   • В случае ошибок токен отклоняется, и клиенту возвращается статус 401 Unauthorized.

Сессии и cookies

Сессии обычно используются в монолитных системах или при работе с браузерами.

Шаги взаимодействия:

1. Аутентификация и создание сессии:
   • Клиент отправляет логин и пароль на сервер аутентификации.
   • Сервер аутентификации создает сессию и возвращает cookie клиенту.
2. Передача сессионного cookie
   • При каждом запросе к основному API серверу клиент автоматически отправляет cookie.
3. Проверка сессии.
   • Основной API сервер проверяет, существует ли сессия в хранилище (например, Redis, Memcached или БД).
   • Если сессия валидна, запрос обрабатывается.

OAuth2 и внешние аутентификационные провайдеры

Шаги взаимодействия:

1. Получение токена от внешнего провайдера:
   • Клиент перенаправляется на сервер внешнего провайдера для аутентификации.
   • После успешной авторизации клиент получает токен доступа.
2. Проверка токена внешнего провайдера:
   • Основной API сервер проверяет токен через сервер аутентификации (перед запросами к внешнему провайдеру или через публичные ключи).

Взаимодействие через внутренние запросы

В некоторых случаях сервер аутентификации и основной API сервер взаимодействуют напрямую через внутренние HTTP-запросы или gRPC.

Шаги:

1. Основной API сервер получает запрос с токеном или сессией.
2. Он отправляет внутренний запрос на сервер аутентификации для проверки.
3. Сервер аутентификации проверяет данные и возвращает результат.

Недостатки:

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

Секретный ключ для jwt создается один раз для генерации всех токенов?

Да, секретный ключ для генерации и валидации JWT обычно создается один раз и используется для всех токенов в рамках одного окружения (например, для продакшена, разработки или тестирования). Он служит основой для подписывания и проверки подлинности всех токенов.

Когда менять секретный ключ?

Секретный ключ не должен меняться часто, так как это приведет к тому, что все существующие токены станут недействительными. Однако есть ситуации, когда замена ключа необходима:

1. Компрометация ключа: Если секретный ключ скомпрометирован (утек или был украден), его необходимо немедленно заменить.
2. Регулярная ротация ключей: Для повышения безопасности можно периодически менять ключи (например, раз в несколько месяцев). Для этого нужно внедрить механизм ротации.

Генерация секретного ключа с помощью OpenSSL:

$ openssl rand -base64 32

Как хранить секретный ключ для генерации jwt токена?

Переменные окружения (Environment Variables)

Самый распространенный и рекомендуемый способ хранения секретных ключей.

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

Пример для Vapor на Swift:

import Vapor

let jwtSecret = Environment.get("JWT_SECRET") ?? "default_secret_key"
app.jwt.signers.use(.hs256(key: jwtSecret))

.env файл (для локальной разработки):

JWT_SECRET=supersecretkey123!

Можно использовать библиотеку для работы с переменными окружения, например DotEnv (SwiftDotEnv).

Преимущества:

• Безопасно — ключ не хранится в коде.
• Гибко — можно использовать разные ключи для разработки, тестирования и продакшена.

Недостатки:

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

Хранилище секретов (Secret Management)

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

Популярные решения:

• AWS Secrets Manager
• HashiCorp Vault
• Azure Key Vault
• Google Cloud Secret Manager

Как это работает:

• Приложение запрашивает ключ у сервиса хранения секретов через API.
• Секрет загружается в рантайме и используется для подписывания JWT.

Пример (псевдокод):

swiftКопировать кодlet secretKey = fetchSecretFromVault("jwt_secret")
app.jwt.signers.use(.hs256(key: secretKey))

Преимущества:

• Высокая безопасность — секреты шифруются и защищаются правами доступа.
• Удобное управление ключами.

Недостатки:

• Требуется дополнительная настройка и интеграция.

Конфигурационные файлы с шифрованием

Хранение секретного ключа в файле конфигурации, но файл должен быть зашифрован.

• Использовать шифрование (например, GPG или OpenSSL) для защиты файла.
• Приложение расшифровывает файл при запуске.

Пример:

1. Зашифрованный конфигурационный файл config.enc.
2. Расшифровка на этапе запуска приложения.
3. Загрузка ключа из расшифрованного файла.

$ gpg --decrypt config.enc > config.json

Преимущества:

• Удобно для хранения конфигураций.
• Защита на уровне шифрования.

Недостатки:

• Необходимо защищать ключ для расшифровки файла.

Аппаратные модули безопасности (HSM)

Использование аппаратных устройств для хранения секретов, таких как Hardware Security Module (HSM) или облачные HSM (например, AWS KMS).

Как это работает:

• Приложение отправляет запрос на HSM для подписывания или валидации JWT.
• Секретный ключ никогда не покидает аппаратное устройство.

Преимущества:

• Самый высокий уровень безопасности.
• Ключи недоступны извне.

Недостатки:

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

Docker Secrets (для контейнеров)

Если приложение развернуто в контейнерах, использовать Docker Secrets или Kubernetes Secrets.

• Секретный ключ сохраняется как Docker Secret.
• Контейнер получает доступ к секрету во время запуска.

Пример для Docker Compose:

version: '3.7'
services:
  app:
    image: my-vapor-app
    secrets:
      - jwt_secret

secrets:
  jwt_secret:
    file: ./jwt_secret.txt

Преимущества:

• Удобно для контейнеризированных сред.
• Секреты защищены и доступны только процессу в контейнере.

Правильные права доступа на сервере

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

$ chmod 600 jwt_secret.key
$ chown root:root jwt_secret.key

Что нельзя делать:

1. Хранить секретный ключ в коде. Такой ключ легко увидеть в репозитории или при статическом анализе кода.
2. Добавлять секреты в публичный репозиторий:
   Использовать .gitignore для исключения .env и других файлов с секретами.
3. Хранить ключи в открытом виде в логах или ошибках. Всегда проверять, что ключи и токены не выводятся в логи.