Bedrud Документация

Bedrud поддерживает несколько методов аутентификации.

JWT (JSON Web Tokens)

Bedrud использует JWT для управления сессиями. При входе сервер возвращает два токена:

  1. Access Token: Короткоживущий (например, 1 час). Используется для доступа к защищённым конечным точкам API.
  2. Refresh Token: Долгоживущий (например, 30 дней). Используется для получения нового Access Token без повторного входа.

Бэкенд проверяет эти токены в файле internal/middleware/auth.go.

Управление токенами и безопасность

1. Стратегия пары токенов (ротация)

Bedrud использует безопасную стратегию ротации токенов. При аутентификации пользователь получает:

  • Access Token: Подписан с помощью HS256, содержит ID пользователя, имя и права. Действителен в течение короткого времени (настраивается через tokenDuration).
  • Refresh Token: Отдельный долгоживущий токен.

Ротация: Когда Access Token истекает, клиент отправляет Refresh Token на /api/auth/refresh. Сервер выдаёт абсолютно новую пару токенов и обновляет сохранённый refresh token в базе данных. Это ограничивает окно возможностей даже в случае кражи токена.

2. Отзыв токенов (чёрный список)

Для поддержки безопасного выхода Bedrud реализует чёрный список токенов.

  • Когда пользователь выходит из системы, его текущий Refresh Token добавляется в таблицу blocked_refresh_tokens.
  • Перед обновлением любой сессии сервер проверяет эту таблицу. Если токен заблокирован, запрос немедленно отклоняется.
  • Фоновая задача (Scheduler) предназначена для очистки заблокированных токенов после их естественного истечения.

3. Структура JWT Claims

Токены содержат метаданные, позволяющие бэкенду и фронтенду принимать быстрые решения без обращений к базе данных:

{
  "userId": "uuid-string",
  "email": "user@example.com",
  "name": "Display Name",
  "accesses": ["user", "admin"],
  "exp": 123456789,
  "iat": 123456780
}

Методы аутентификации

1. Локальная электронная почта и пароль

  • Пароли хешируются с использованием bcrypt - никогда не хранятся в открытом виде.
  • При регистрации в базе данных создаётся новая запись User.

2. Социальный вход (OAuth2)

Bedrud использует библиотеку Goth для поддержки:

  • Google
  • GitHub
  • Twitter

Вы можете включить их, заполнив раздел auth: в вашем config.yaml с вашим Client ID и API Secret.

3. Passkeys (WebAuthn/FIDO2)

Bedrud поддерживает беспарольную аутентификацию через стандарт FIDO2 (WebAuthn).

  • Церемония регистрации:
    1. Начало: Сервер генерирует криптографически защищённый Challenge и сохраняет его в сессии пользователя.
    2. Завершение: Аутентификатор клиента (например, TouchID, YubiKey) подписывает challenge. Сервер проверяет аттестацию, извлекает публичный ключ и сохраняет его в таблице passkeys.
  • Церемония аутентификации:
    1. Начало: Сервер выдаёт новый challenge.
    2. Завершение: Клиент подписывает challenge своим приватным ключом. Сервер извлекает публичный ключ из базы данных, проверяет подпись и проверяет счётчик подписей.
  • Безопасность: Сравнение поля Counter предотвращает атаки повторного воспроизведения. Если счётчик аутентификатора не выше сохранённого счётчика, вход отклоняется.

4. Гостевой вход

Позволяет пользователям мгновенно присоединиться к встрече, указав только имя. Сервер создаёт временную запись пользователя с ролью guest.

Совместимость и CORS

Bedrud спроектирован так, чтобы быть доступным из нескольких источников, что важно для разработки (React dev-сервер) и продакшена (разные поддомены).

  • Политика CORS: Определена в config.yaml. Поддерживает AllowCredentials: true, что необходимо для сессионных файлов cookie, используемых во время церемоний OAuth и Passkey.
  • Разрешённые источники: По умолчанию разрешает собственный домен сервера и localhost:3000 (порт React dev-сервера).

Роли пользователей (управление доступом)

Каждый пользователь имеет список «accesses» (ролей).

  • user: Обычный пользователь. Может присоединяться к комнатам и создавать их.
  • guest: Временный пользователь. Может присоединяться к комнатам.
  • superadmin: Может управлять всеми пользователями и комнатами через панель /admin.

Защита middleware.RequireAccess("superadmin") охраняет маршруты администратора.