Authentifizierungsmethoden

E-Mail-/Passwort-Anmeldung nutzt Better Auth mit Argon2-Hashing. Registrierung verlangt eine E-Mail-Verifizierung; Passwortregeln werden serverseitig anhand aufgelöster Template-Einstellungen geprüft.

Einmal-Codes

Das Better-Auth-Plugin emailOTP versendet sechsstellige Codes, speichert sie gehasht, erlaubt fünf Versuche und lässt sie nach zwei Stunden ablaufen. Die vorhandene UI nutzt Codes für passwortlose Anmeldung, Registrierungsbestätigung und Passwortwiederherstellung.

Passwortwiederherstellung

1. Fordern Sie die Wiederherstellung unter /auth/forgot-password an.
2. Die E-Mail-Vorlage forgotPassword enthält einen Code und einen Link zu /auth/otp mit Wiederherstellungstyp und E-Mail-Kennung.
3. Senden Sie Code und neues Passwort im OTP-Formular ab. Nach erfolgreichem Reset werden bestehende Sitzungen widerrufen und Sie gelangen zu /auth/login.

Der Ablauf nutzt keine separate Seite /auth/reset-password. Halten Sie Verifizierung und Reset-Mutation zusammen; eine erfolgreiche Codeprüfung ist keine allgemeine angemeldete Sitzung.

Google- und GitHub-Anmeldung

Setzen Sie GOOGLE_CLIENT_ID / GOOGLE_CLIENT_SECRET oder GITHUB_CLIENT_ID / GITHUB_CLIENT_SECRET. Callback-URLs verwenden den endgültigen Ursprung der Website:

• /api/auth/callback/google
• /api/auth/callback/github

Sichtbare Schaltflächen werden zur Buildzeit über NEXT_PUBLIC_AUTH_GOOGLE_ENABLED und NEXT_PUBLIC_AUTH_GITHUB_ENABLED gesteuert. Ohne explizite Werte leitet die Next-Konfiguration sie aus Zugangsdaten ab; bauen Sie nach Änderungen neu. Der Server benötigt weiterhin gültige Anbieterzugangsdaten.

Apple- und Microsoft-Anmeldung

Apple: erstellen Sie eine Services ID, die mit einer App ID für Sign in with Apple verbunden ist. Registrieren Sie Domain und exakte HTTPS-Rückleitungs-URL /api/auth/callback/apple auf dem endgültigen Ursprung aus NEXT_PUBLIC_SITE_URL. Setzen Sie APPLE_CLIENT_ID auf die Services ID und APPLE_CLIENT_SECRET auf ein ES256-Client-Secret-JWT, signiert mit Ihrem privaten Apple-Schlüssel. Das JWT benötigt Team ID, Key ID, Services ID, Apple-Audience, Ausstellungszeit und Ablaufzeit. Folgen Sie Apples Anleitung; die Laufzeit darf etwa sechs Monate nicht überschreiten. Erneuern Sie das Secret vor Ablauf. Registrieren Sie Absenderdomains/-adressen für Apples private E-Mail-Weiterleitung und prüfen Sie die Zustellung an Relay-Adressen.

Microsoft: registrieren Sie in Microsoft Entra eine Webanwendung mit /api/auth/callback/microsoft auf dem endgültigen Website-Ursprung. Setzen Sie MICROSOFT_CLIENT_ID und MICROSOFT_CLIENT_SECRET. Stimmen Sie die unterstützten Kontotypen der Registrierung mit MICROSOFT_TENANT_ID ab: common (Standard) für Organisations- und Privatkonten, organizations für Arbeits-/Schulkonten, consumers für Privatkonten oder eine Tenant-UUID für einen einzelnen Mandanten. Dokumentieren Sie Ablauf und Erneuerung des Client-Secrets in der Deployment-Konfiguration.

Setzen Sie NEXT_PUBLIC_AUTH_APPLE_ENABLED=true beziehungsweise NEXT_PUBLIC_AUTH_MICROSOFT_ENABLED=true vor dem Build, wenn Zugangsdaten erst beim Containerstart verfügbar sind. Sonst leitet die Next-Konfiguration diese Flags aus den beim Build vorhandenen Zugangsdaten ab. Die Flags enthalten keine Secrets und ersetzen keine Serverzugangsdaten. Der Server registriert einen Anbieter erst, wenn beide Zugangsdaten vorhanden sind.

Die Abläufe verwenden Better Auths bestehende Kontoverknüpfung und verlangen eine nutzbare E-Mail-Angabe. Fehlt sie, erscheint ein Anmeldefehler; die Anwendung erfindet keine E-Mail-Adresse. Prüfen Sie vor dem Start erste und wiederholte Anmeldung, abgebrochene Autorisierung, die gewählten Microsoft-Kontotypen und Apple-Relay-Mail auf der endgültigen HTTPS-Domain. Lokale Konfigurationsprüfungen belegen diese externen Abläufe nicht.

Siehe Rollen & Berechtigungen.