Bedrud unterstützt mehrere Authentifizierungsmethoden.

JWT (JSON Web Tokens)

Bedrud verwendet JWT für die Sitzungsverwaltung. Bei der Anmeldung gibt der Server zwei Tokens zurück:

1. Access Token: Kurzlebig (z. B. 1 Stunde). Wird verwendet, um auf geschützte API-Endpunkte zuzugreifen.
2. Refresh Token: Langlebig (z. B. 30 Tage). Wird verwendet, um ein neues Access Token zu erhalten, ohne sich erneut anmelden zu müssen.

Das Backend validiert diese Tokens in der Datei internal/middleware/auth.go.

Token-Verwaltung & Sicherheit

1. Token-Paar-Strategie (Rotation)

Bedrud verwendet eine sichere Token-Rotationsstrategie. Wenn sich ein Benutzer authentifiziert, erhält er:

• Access Token: Mit HS256 signiert, enthält Benutzer-ID, Namen und Berechtigungen. Gültig für einen kurzen Zeitraum (konfigurierbar über tokenDuration).
• Refresh Token: Ein separates, langlebiges Token.

Rotation: Wenn das Access Token abläuft, sendet der Client das Refresh Token an /api/auth/refresh. Der Server stellt dann ein komplett neues Paar an Tokens aus und aktualisiert das gespeicherte Refresh Token in der Datenbank. Dies begrenzt das Zeitfenster, selbst wenn ein Token gestohlen wurde.

2. Token-Sperrung (Blacklisting)

Um eine sichere Abmeldung zu unterstützen, implementiert Bedrud eine Token-Blacklist.

• Wenn sich ein Benutzer abmeldet, wird sein aktuelles Refresh Token zur Tabelle blocked_refresh_tokens hinzugefügt.
• Vor der Aktualisierung einer Sitzung prüft der Server diese Tabelle. Wenn ein Token blockiert ist, wird die Anfrage sofort abgelehnt.
• Eine Hintergrundaufgabe (Scheduler) ist dafür vorgesehen, diese blockierten Tokens zu bereinigen, sobald sie auf natürliche Weise ablaufen.

3. JWT-Claims-Struktur

Die Tokens enthalten Metadaten, die es dem Backend und Frontend ermöglichen, schnelle Entscheidungen ohne Datenbankabfragen zu treffen:

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

Authentifizierungsmethoden

1. Lokale E-Mail & Passwort

• Passwörter werden mit bcrypt gehasht – niemals als Klartext gespeichert.
• Bei der Registrierung wird ein neuer Benutzer-Datensatz in der Datenbank erstellt.

2. Social Login (OAuth2)

Bedrud verwendet die Goth-Bibliothek zur Unterstützung von:

• Google
• GitHub
• Twitter

Sie können diese aktivieren, indem Sie den Abschnitt auth: in Ihrer config.yaml mit Ihrer Client-ID und Ihrem API-Secret ausfüllen.

3. Passkeys (WebAuthn/FIDO2)

Bedrud unterstützt passwortlose Authentifizierung über den FIDO2-Standard (WebAuthn).

• Registrierungszeremonie:
  1. Beginn: Der Server generiert eine kryptografisch sichere Challenge und speichert sie in der Benutzersitzung.
  2. Abschluss: Der Authenticator des Clients (z. B. TouchID, YubiKey) signiert die Challenge. Der Server verifiziert die Attestierung, extrahiert den Public Key und speichert ihn in der Tabelle passkeys.
• Authentifizierungszeremonie:
  1. Beginn: Der Server stellt eine neue Challenge aus.
  2. Abschluss: Der Client signiert die Challenge mit seinem privaten Schlüssel. Der Server ruft den Public Key aus der Datenbank ab, verifiziert die Signatur und prüft den Sign Counter.
• Sicherheit: Der Abgleich des Counter-Felds verhindert Replay-Angriffe. Wenn der Zähler des Authenticators nicht höher ist als der gespeicherte Zähler, wird die Anmeldung abgelehnt.

4. Gast-Anmeldung

Ermöglicht Benutzern, sofort mit nur einem Namen an einem Meeting teilzunehmen. Der Server erstellt einen temporären Benutzer-Datensatz mit der Rolle guest.

E-Mail-Verifizierung

Wenn requireEmailVerification: true in der Konfiguration gesetzt ist, erfordern die lokale (Nicht-OAuth) Registrierung und Anmeldung eine E-Mail-Bestätigung:

• Registrierung erstellt den Benutzer, setzt aber EmailVerifiedAt auf nil. Der Benutzer kann sich erst nach Verifizierung anmelden.
• Anmeldung gibt 403 mit {"requiresVerification": true} für nicht verifizierte Konten zurück.
• Erneutes Senden via POST /api/auth/verify/resend — ratenbegrenzt durch verificationEmailCooldownMins und einen separaten Rate-Limit-Bucket (authResendMaxRequests).
• Auto-Bereinigung löscht nicht verifizierte Konten nach unverifiedAccountTTLHours (Standard 48h, 0 zum Deaktivieren).
• E-Mail-Änderung löst einen neuen Verifizierungsvorgang aus. Der Benutzer bleibt angemeldet; ein neues Token wird ausgestellt.

Gastbenutzer sind ausgenommen — sie haben keine E-Mail.

Passwort-Zurücksetzen

Passwort-Zurücksetzen-Ablauf (erfordert SMTP):

1. POST /api/auth/forgot-password mit {"email": "..."} — der Server sendet einen Link zum Zurücksetzen an die E-Mail
2. POST /api/auth/reset-password mit {"token": "...", "newPassword": "..."} — setzt ein neues Passwort

Die Token-Lebensdauer wird durch resetTokenTTLHours gesteuert (Standard 1 Stunde). Der Forgot-Password-Endpunkt teilt sich den Auth-Rate-Limit-Bucket.

Abklingzeit & Ratenbegrenzung

Bedrud verwendet vier separate Rate-Limit-Buckets:

Bucket auf 0 gesetzt = deaktiviert. Alle Limits pro Remote-IP. Bei Überschreitung wird 429 Too Many Requests mit Retry-After-Header zurückgegeben.

Interoperabilität & CORS

Bedrud ist so konzipiert, dass es von mehreren Origins aus erreichbar ist, was für die Entwicklung (React-Dev-Server) und die Produktion (verschiedene Subdomains) unerlässlich ist.

• CORS-Richtlinie: Definiert in config.yaml. Sie unterstützt AllowCredentials: true, was für die Session-Cookies erforderlich ist, die während OAuth- und Passkey-Zeremonien verwendet werden.
• Erlaubte Origins: Standardmäßig sind die eigene Domäne des Servers und localhost:3000 (der React-Dev-Server-Port) erlaubt.

Benutzerrollen (Zugriffskontrolle)

Jeder Benutzer verfügt über ein accesses-Array, das mehrere Zugriffsebenen gleichzeitig enthalten kann. Die JWT-Claims enthalten das vollständige accesses-Array, sodass die Middleware granulare Berechtigungen prüfen kann.

Zugriffsebenen

Rollenhierarchie

superadmin > admin > moderator > user > guest

Ein superadmin kann jede Moderationsaktion in jedem Raum durchführen, ohne als Raum-Moderator befördert zu werden. Raumersteller sind automatisch Raum-Admins und können Teilnehmer zum Moderator befördern.

Rollenzuweisung

Rollen werden über mehrere Kanäle verwaltet:

• CLI: bedrud user create (erstellt als user), bedrud user promote (fügt superadmin hinzu), bedrud user demote (entfernt superadmin)
• Admin-Dashboard: Benutzerdetailseite hat Befördern-/Herabstufen-Schaltflächen
• Admin-API: PUT /api/admin/users/:id/accesses mit gewünschtem accesses-Array
• Im Meeting: Raumersteller können Teilnehmer zum Raum-Moderator befördern

Hinweis: Es gibt keinen API-Endpunkt oder keine Weboberfläche zum Erstellen des ersten Superadmins. Nach der Installation müssen Sie die CLI (bedrud user create + bedrud user promote) verwenden, um den initialen Admin-Zugriff einzurichten. Dies ist eine bewusste Sicherheitsmaßnahme.