Bedrud prend en charge plusieurs méthodes d’authentification.

JWT (JSON Web Tokens)

Bedrud utilise JWT pour la gestion de session. Lors de la connexion, le serveur renvoie deux jetons :

1. Jeton d’Accès (Access Token) : À courte durée de vie (ex: 1 heure). Utilisé pour accéder aux points de terminaison API protégés.
2. Jeton de Rafraîchissement (Refresh Token) : À longue durée de vie (ex: 30 jours). Utilisé pour obtenir un nouveau Jeton d’Accès sans se reconnecter.

Le backend valide ces jetons dans le fichier internal/middleware/auth.go.

Gestion & Sécurité des Jetons

1. Stratégie de Paire de Jetons (Rotation)

Bedrud utilise une stratégie de rotation sécurisée des jetons. Lorsqu’un utilisateur s’authentifie, il reçoit :

• Jeton d’Accès : Signé avec HS256, contient l’ID utilisateur, le nom et les permissions. Valide pour une courte durée (configuré via tokenDuration).
• Jeton de Rafraîchissement : Un jeton distinct à longue durée de vie.

Rotation : Lorsque le Jeton d’Accès expire, le client envoie le Jeton de Rafraîchissement à /api/auth/refresh. Le serveur émet alors une nouvelle paire complète de jetons et met à jour le jeton de rafraîchissement stocké dans la base de données. Cela limite la fenêtre d’opportunité même si un jeton est volé.

2. Révocation de Jeton (Liste Noire)

Pour supporter une déconnexion sécurisée, Bedrud implémente une Liste Noire de Jetons.

• Lorsqu’un utilisateur se déconnecte, son Jeton de Rafraîchissement actuel est ajouté à la table blocked_refresh_tokens.
• Avant de rafraîchir toute session, le serveur vérifie cette table. Si un jeton est bloqué, la requête est immédiatement rejetée.
• Une tâche en arrière-plan (Scheduler) est conçue pour nettoyer ces jetons bloqués une fois qu’ils expirent naturellement.

3. Structure des Claims JWT

Les jetons portent des métadonnées qui permettent au backend et au frontend de prendre des décisions rapides sans accès à la base de données :

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

Méthodes d’Authentification

1. Email & Mot de Passe Local

• Les mots de passe sont hachés en utilisant bcrypt - jamais stockés en texte brut.
• Lors de l’inscription, un nouvel enregistrement Utilisateur est créé dans la base de données.

2. Connexion Sociale (OAuth2)

Bedrud utilise la bibliothèque Goth pour supporter :

• Google
• GitHub
• Twitter

Vous pouvez activer ces services en remplissant la section auth: dans votre config.yaml avec votre ID Client et Secret API.

3. Passkeys (WebAuthn/FIDO2)

Bedrud supporte l’authentification sans mot de passe via le standard FIDO2 (WebAuthn).

• Cérémonie d’Inscription :
  1. Début : Le serveur génère un Challenge cryptographiquement sécurisé et le stocke dans la session de l’utilisateur.
  2. Fin : L’authentificateur du client (ex: TouchID, YubiKey) signe le challenge. Le serveur vérifie l’attestation, extrait la Clé Publique, et la sauvegarde dans la table passkeys.
• Cérémonie d’Authentification :
  1. Début : Le serveur émet un nouveau challenge.
  2. Fin : Le client signe le challenge avec sa clé privée. Le serveur récupère la Clé Publique de la base de données, vérifie la signature, et vérifie le Compteur de Signe (Sign Counter).
• Sécurité : La correspondance du champ Counter empêche les Attaques par Rejeu. Si le compteur de l’authentificateur n’est pas supérieur au compteur stocké, la connexion est rejetée.

4. Connexion Invité

Permet aux utilisateurs de rejoindre une réunion instantanément avec juste un nom. Le serveur crée un enregistrement utilisateur temporaire avec le rôle guest.

Vérification des e-mails

Lorsque requireEmailVerification: true est défini dans la configuration, l’inscription et la connexion locales (non OAuth) nécessitent une confirmation par e-mail :

• Inscription crée l’utilisateur mais définit EmailVerifiedAt à nil. L’utilisateur ne peut pas se connecter tant qu’il n’est pas vérifié.
• Connexion renvoie 403 avec {"requiresVerification": true} pour les comptes non vérifiés.
• Renvoyer via POST /api/auth/verify/resend — limité par verificationEmailCooldownMins et un compartiment de limite de débit séparé (authResendMaxRequests).
• Nettoyage automatique supprime les comptes non vérifiés après unverifiedAccountTTLHours (48h par défaut, 0 pour désactiver).
• Changement d’e-mail déclenche un nouveau flux de vérification. L’utilisateur reste connecté ; un nouveau jeton est émis.

Les utilisateurs invités sont exemptés — ils n’ont pas d’e-mail.

Réinitialisation du mot de passe

Processus de réinitialisation du mot de passe (nécessite SMTP) :

1. POST /api/auth/forgot-password avec {"email": "..."} — le serveur envoie un lien de réinitialisation par e-mail
2. POST /api/auth/reset-password avec {"token": "...", "newPassword": "..."} — définit un nouveau mot de passe

La durée de vie du jeton de réinitialisation est contrôlée par resetTokenTTLHours (1 heure par défaut). Le point d’accès forgot-password partage le compartiment de limite de débit Auth.

Limitation de débit & Refroidissement

Bedrud utilise quatre compartiments de limite de débit distincts :

Compartiment à 0 = désactivé. Toutes les limites par IP distante. Les requêtes excessives renvoient 429 Too Many Requests avec l’en-tête Retry-After.

Interopérabilité & CORS

Bedrud est conçu pour être accessible depuis plusieurs origines, ce qui est crucial pour le développement (serveur dev React) et la production (sous-domaines différents).

• Politique CORS : Définie dans config.yaml. Elle supporte AllowCredentials: true, ce qui est requis pour les cookies de session utilisés pendant les cérémonies OAuth et Passkey.
• Origines Autorisées : Par défaut, elle permet le propre domaine du serveur et localhost:3000 (le port du serveur dev React).

Rôles Utilisateur (Contrôle d’Accès)

Chaque utilisateur possède un tableau accesses qui peut contenir plusieurs niveaux d’accès simultanément. Les claims JWT incluent le tableau accesses complet, permettant au middleware de vérifier des permissions granulaires.

Niveaux d’Accès

Hiérarchie des Rôles

superadmin > admin > moderator > user > guest

Un superadmin peut effectuer n’importe quelle action de modération dans n’importe quelle salle sans être promu modérateur de salle. Les créateurs de salle sont automatiquement admins de leur salle et peuvent promouvoir des participants au rôle de modérateur.

Attribution des Rôles

Les rôles sont gérés via plusieurs canaux :

• CLI : bedrud user create (crée en tant que user), bedrud user promote (ajoute superadmin), bedrud user demote (retire superadmin)
• Tableau de bord administrateur : La page de détail utilisateur a des boutons promouvoir/rétrograder
• API Admin : PUT /api/admin/users/:id/accesses avec le tableau accesses souhaité
• En réunion : Le créateur de la salle peut promouvoir des participants au rôle de modérateur de salle

Note : Il n’y a pas de point de terminaison API ni d’interface web pour créer le premier superadmin. Après l’installation, vous devez utiliser la CLI (bedrud user create + bedrud user promote) pour initialiser l’accès admin. C’est une mesure de sécurité délibérée.