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.

Подтверждение email

Когда в конфигурации установлено requireEmailVerification: true, локальная (не OAuth) регистрация и вход требуют подтверждения email:

• Регистрация создает пользователя, но устанавливает EmailVerifiedAt в nil. Пользователь не может войти до подтверждения.
• Вход возвращает 403 с {"requiresVerification": true} для неподтвержденных аккаунтов.
• Повторная отправка через POST /api/auth/verify/resend — ограничено verificationEmailCooldownMins и отдельным ведром лимита (authResendMaxRequests).
• Автоочистка удаляет неподтвержденные аккаунты после unverifiedAccountTTLHours (по умолчанию 48ч, 0 для отключения).
• Смена email запускает новый процесс подтверждения. Пользователь остается в системе; выдается новый токен.

Гостевые пользователи освобождены — у них нет email.

Сброс пароля

Процесс сброса пароля (требуется SMTP):

1. POST /api/auth/forgot-password с {"email": "..."} — сервер отправляет ссылку для сброса на email
2. POST /api/auth/reset-password с {"token": "...", "newPassword": "..."} — устанавливает новый пароль

TTL токена сброса управляется resetTokenTTLHours (по умолчанию 1 час). Эндпоинт forgot-password разделяет ведро лимита Auth.

Охлаждение и ограничение скорости

Bedrud использует четыре отдельных ведра ограничения скорости:

Ведро 0 = отключено. Все лимиты на удаленный IP. Превышенные запросы возвращают 429 Too Many Requests с заголовком Retry-After.

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

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

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

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

Каждый пользователь имеет массив accesses, который может одновременно содержать несколько уровней доступа. JWT-токен включает полный массив accesses, что позволяет middleware проверять детальные разрешения.

Уровни доступа

Иерархия ролей

superadmin > admin > moderator > user > guest

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

Назначение ролей

Роли управляются через несколько каналов:

• CLI: bedrud user create (создаёт с уровнем user), bedrud user promote (добавляет superadmin), bedrud user demote (убирает superadmin)
• Панель администратора: На странице деталей пользователя есть кнопки повышения/понижения
• API администратора: PUT /api/admin/users/:id/accesses с желаемым массивом accesses
• Во время встречи: Создатель комнаты может повышать участников до модераторов комнаты

Примечание: Не существует эндпоинта API или веб-интерфейса для создания первого суперадминистратора. После установки необходимо использовать CLI (bedrud user create + bedrud user promote) для начальной настройки административного доступа. Это осознанная мера безопасности.