Bedrud admite múltiples métodos de autenticación.

JWT (JSON Web Tokens)

Bedrud utiliza JWT para la gestión de sesiones. Al iniciar sesión, el servidor devuelve dos tokens:

1. Token de Acceso: De corta duración (por ejemplo, 1 hora). Se utiliza para acceder a los endpoints protegidos de la API.
2. Token de Refresco: De larga duración (por ejemplo, 30 días). Se utiliza para obtener un nuevo Token de Acceso sin necesidad de volver a iniciar sesión.

El backend valida estos tokens en el archivo internal/middleware/auth.go.

Gestión y Seguridad de Tokens

1. Estrategia de Par de Tokens (Rotación)

Bedrud utiliza una estrategia segura de rotación de tokens. Cuando un usuario se autentica, recibe:

• Token de Acceso: Firmado con HS256, contiene el ID de usuario, nombre y permisos. Válido por un periodo corto (configurado mediante tokenDuration).
• Token de Refresco: Un token separado de larga duración.

Rotación: Cuando el Token de Acceso expira, el cliente envía el Token de Refresco a /api/auth/refresh. El servidor entonces emite un par completamente nuevo de tokens y actualiza el token de refresco almacenado en la base de datos. Esto limita la ventana de oportunidad incluso si un token es robado.

2. Revocación de Tokens (Lista Negra)

Para admitir el cierre de sesión de forma segura, Bedrud implementa una Lista Negra de Tokens.

• Cuando un usuario cierra sesión, su Token de Refresco actual se añade a la tabla blocked_refresh_tokens.
• Antes de refrescar cualquier sesión, el servidor verifica esta tabla. Si un token está bloqueado, la solicitud se rechaza inmediatamente.
• Una tarea en segundo plano (Scheduler) está diseñada para limpiar estos tokens bloqueados una vez que expiran naturalmente.

3. Estructura de los Claims JWT

Los tokens contienen metadatos que permiten al backend y al frontend tomar decisiones rápidas sin consultas a la base de datos:

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

Métodos de Autenticación

1. Correo Electrónico y Contraseña Local

• Las contraseñas se hashean mediante bcrypt - nunca se almacenan en texto plano.
• Al registrarte, se crea un nuevo registro de usuario en la base de datos.

2. Inicio de Sesión Social (OAuth2)

Bedrud utiliza la librería Goth para admitir:

• Google
• GitHub
• Twitter

Puedes habilitarlos rellenando la sección auth: en tu config.yaml con tu Client ID y API Secret.

3. Passkeys (WebAuthn/FIDO2)

Bedrud admite autenticación sin contraseña mediante el estándar FIDO2 (WebAuthn).

• Ceremonia de Registro:
  1. Inicio: El servidor genera un Challenge criptográficamente seguro y lo almacena en la sesión del usuario.
  2. Finalización: El autenticador del cliente (por ejemplo, TouchID, YubiKey) firma el challenge. El servidor verifica la atestación, extrae la Clave Pública y la guarda en la tabla passkeys.
• Ceremonia de Autenticación:
  1. Inicio: El servidor emite un nuevo challenge.
  2. Finalización: El cliente firma el challenge con su clave privada. El servidor recupera la Clave Pública de la base de datos, verifica la firma y comprueba el Contador de Signatura.
• Seguridad: La verificación del campo Counter previene Ataques de Reproducción. Si el contador del autenticador no es superior al contador almacenado, el inicio de sesión se rechaza.

4. Inicio de Sesión como Invitado

Permite a los usuarios unirse a una reunión al instante con solo un nombre. El servidor crea un registro de usuario temporal con el rol guest.

Verificación de correo electrónico

Cuando requireEmailVerification: true está configurado, el registro e inicio de sesión local (no OAuth) requieren confirmación por correo electrónico:

• Registro crea el usuario pero establece EmailVerifiedAt en nil. El usuario no puede iniciar sesión hasta que se verifique.
• Inicio de sesión devuelve 403 con {"requiresVerification": true} para cuentas no verificadas.
• Reenviar mediante POST /api/auth/verify/resend — limitado por verificationEmailCooldownMins y un depósito de límite de velocidad separado (authResendMaxRequests).
• Limpieza automática elimina cuentas no verificadas después de unverifiedAccountTTLHours (48h por defecto, 0 para deshabilitar).
• Cambio de correo desencadena un nuevo flujo de verificación. El usuario permanece conectado; se emite un nuevo token.

Los usuarios invitados están exentos — no tienen correo electrónico.

Restablecimiento de contraseña

Flujo de restablecimiento de contraseña (requiere SMTP):

1. POST /api/auth/forgot-password con {"email": "..."} — el servidor envía un enlace de restablecimiento al correo electrónico
2. POST /api/auth/reset-password con {"token": "...", "newPassword": "..."} — establece una nueva contraseña

El TTL del token de restablecimiento está controlado por resetTokenTTLHours (1 hora por defecto). El endpoint forgot-password comparte el depósito de límite de velocidad de Auth.

Límite de velocidad & Enfriamiento

Bedrud utiliza cuatro depósitos de límite de velocidad separados:

Depósito en 0 = desactivado. Todos los límites por IP remota. Las solicitudes que excedan devuelven 429 Too Many Requests con el encabezado Retry-After.

Interoperabilidad y CORS

Bedrud está diseñado para ser accesible desde múltiples orígenes, lo cual es fundamental tanto para el desarrollo (servidor de desarrollo de React) como para producción (diferentes subdominios).

• Política CORS: Definida en config.yaml. Admite AllowCredentials: true, lo cual es necesario para las cookies de sesión utilizadas durante las ceremonias de OAuth y Passkeys.
• Orígenes Permitidos: Por defecto, permite el dominio propio del servidor y localhost:3000 (el puerto del servidor de desarrollo de React).

Roles de Usuario (Control de Acceso)

Cada usuario tiene un arreglo accesses que puede contener múltiples niveles de acceso simultáneamente. Los claims del JWT incluyen el arreglo accesses completo, permitiendo al middleware verificar permisos granulares.

Niveles de Acceso

Jerarquía de Roles

superadmin > admin > moderator > user > guest

Un superadmin puede realizar cualquier acción de moderación en cualquier sala sin ser promovido como moderador de sala. Los creadores de salas son automáticamente administradores de sala y pueden promover participantes a moderador.

Asignación de Roles

Los roles se gestionan a través de múltiples canales:

• CLI: bedrud user create (crea como user), bedrud user promote (agrega superadmin), bedrud user demote (elimina superadmin)
• Panel de Administración: La página de detalle de usuario tiene botones de promover/degradar
• API de Administración: PUT /api/admin/users/:id/accesses con el arreglo accesses deseado
• Durante la Reunión: El creador de la sala puede promover participantes a moderador a nivel de sala

Nota: No hay un endpoint de API ni interfaz web para crear el primer superadmin. Después de la instalación, debe usar la CLI (bedrud user create + bedrud user promote) para iniciar el acceso de administración inicial. Esta es una medida de seguridad deliberada.