22. Authentication

Die öffentlichen Endpunkte (Abschnitt 20)

Die in 20-api.md dokumentierten Endpunkte erfordern keine Authentifizierung — sie sind absichtlich öffentlich (siehe 21-api-keys.md für die Begründung).

Die PRONTO-Anwendung selbst

Für alle eingeloggten Bereiche (CRM, Kalender, Formulare, Newsletter-Verwaltung, …) nutzt PRONTO Supabase Auth mit E-Mail/Passwort:

1. Login liefert ein Supabase-Session-JWT.
2. Jeder interne Server-Aufruf (TanStack-Start-createServerFn) prüft dieses Token über die requireProntoAuth-Middleware und liest daraus die userId — niemals aus vom Client mitgesendeten Feldern.
3. Die raw-API-Route /api/public/pronto-ai/chat (PRONTO-AI-Chat, aktuell deaktiviert, siehe 14-ki.md) verlangt denselben Token als Authorization: Bearer <jwt> -Header, da für rohe Routen (kein createServerFn) keine Middleware greift.

Eigenständige Zusatzsysteme (kein Supabase-Auth-Hook)

Zwei sicherheitsrelevante Abläufe laufen bewusst außerhalb von Supabase Auth Hooks, über eigene, unabhängige Tabellen und Zufalls-Token:

• E-Mail-Bestätigung: 6-stelliger Code, gehasht in email_verification_codes, 15 Minuten gültig.
• Passwort-Reset: 32-Byte-Zufalls-Token, gehasht (SHA-256) in password_reset_tokens, 15 Minuten gültig, einmalig verwendbar.

Admin-Zugriff

Admin-Rechte werden nicht in der Datenbank gespeichert, sondern anhand einer festen E-Mail-Liste in der Server-Umgebungsvariable PRONTO_ADMIN_EMAILS geprüft (istAdmin(userId)), bei jedem Aufruf serverseitig neu ausgewertet.