Supabase Auth: Login in eine mit KI gebaute Web-App einbauen

Supabase Auth ist das in Supabase eingebaute Login-System: Es speichert die Nutzer in der Postgres-Datenbank Ihres Projekts, meldet sie per Passwort, Magic Link, Einmalcode oder über einen Anbieter wie Google an und stellt die Session aus, die Ihre Datenbankregeln auslesen. Um Login in eine Web-App einzubauen, nennen Sie Ihrem KI-App-Baukasten die Anmeldemethoden und die Rollen und prüfen dann drei Einstellungen im Supabase-Dashboard: die Site URL, die Redirect-URLs und den E-Mail-Absender.

Dieser Leitfaden erklärt, was jeder Teil leistet, welche Entscheidungen zählen und welche Sätze in Ihren Prompt gehören. Die Zugriffsregeln selbst behandelt unser Leitfaden zu Supabase Row Level Security.

Was Supabase Auth leistet und was nicht

Supabase Auth belegt, wer ein Nutzer ist; es entscheidet nicht, was dieser Nutzer sehen darf. Die Dokumentation listet die Anmeldemethoden auf: Passwort, Magic Link, Einmalpasswort, Social Login (Apple, Google, GitHub und jeder OAuth2- oder OIDC-Anbieter), Telefon über Anbieter wie Twilio und Single Sign-on per SAML für Unternehmen. Die Nutzerdaten liegen in einem eigenen Schema Ihrer Postgres-Datenbank.

Was ein Nutzer tun darf, ist eine zweite Ebene. Der Supabase-Client sendet den Token des Nutzers mit jeder Anfrage, und Row-Level-Security-Policies in der Datenbank filtern damit die Zeilen. Die Authentifizierung beantwortet „Wer ist das?“, die Policies beantworten „Welche Zeilen darf diese Person lesen oder ändern?“. Eine App mit Login, aber ohne Policies ist offen.

Welche Anmeldemethode die richtige ist

Wählen Sie die Methode, die zum Verhalten Ihrer Nutzer passt: Google für Endkunden oder Startups, E-Mail und Passwort für Business-Tools, Magic Link, wenn man sich selten anmeldet. Jede hat ihren Preis, die Übersicht:

E-Mail-Bestätigung und Passwort-Reset

Ist die E-Mail-Bestätigung aktiv, kann sich ein neuer Nutzer erst anmelden, wenn er auf den Link in der Nachricht klickt. Auf der Konfigurationsseite von Supabase steht: Schalten Sie sie aus, gilt die E-Mail ohne jede Prüfung als bestätigt. Lassen Sie sie bei allem mit echten Nutzern an: Ohne sie kann jeder ein Konto mit einer fremden Adresse anlegen.

Der Passwort-Reset funktioniert genauso: Der Nutzer fordert einen Link an, erhält eine E-Mail und landet auf einer Seite Ihrer App, auf der er ein neues Passwort wählt. Beide Abläufe hängen von zwei Dingen ab, die Sie selbst steuern: den Redirect-Einstellungen unten und dem E-Mail-Absender. Öffnet ein Bestätigungslink „localhost“ oder eine Fehlerseite, liegt die Ursache fast immer in den Redirect-Einstellungen.

Sessions: was nach dem Login passiert

Nach dem Login gibt Supabase dem Browser einen kurzlebigen Access Token und einen Refresh Token, und die Client-Bibliothek erneuert sie, ohne dass sich der Nutzer erneut anmelden muss. Laut der Dokumentation zu Sessions ist der Access Token ein JWT, das standardmäßig nach 1 Stunde abläuft, und jeder Refresh Token lässt sich nur einmal verwenden. Wird ein alter Refresh Token außerhalb eines kurzen Zeitfensters erneut vorgelegt, wird die ganze Session beendet.

Für Nutzer eines Baukastens heißt das praktisch: Sie schreiben kaum Session-Code. Sie bitten um „Nutzer angemeldet halten“ und „Abgemeldete auf die Login-Seite umleiten“, und die generierte App erledigt den Rest über die Client-Bibliothek.

auth.users oder eine Tabelle profiles

Belassen Sie den Login-Eintrag in auth.users und alles Weitere über die Person in einer eigenen Tabelle, meist profiles genannt. Der Supabase-Leitfaden zu Nutzerdaten verwalten erklärt den Grund: Das Auth-Schema ist in der automatischen API nicht freigegeben, Ihre App kann es also nicht direkt lesen. Das empfohlene Muster ist eine öffentliche Tabelle profiles, deren id auf auth.users verweist (mit on delete cascade) und bei der Row Level Security aktiv ist, dazu ein Trigger, der nach jeder Registrierung die Profilzeile anlegt.

Derselbe Leitfaden warnt, dass ein fehlerhafter Trigger Registrierungen blockieren kann. Testen Sie ihn deshalb nach jeder Änderung an der Tabelle mit einem echten neuen Konto. Das ist eine häufige Ursache für „Database error saving new user“, nachdem eine KI das Schema geändert hat.

Rollen: Admin, Mitglied, Kunde

Speichern Sie die Rolle in Ihrer eigenen Tabelle, nicht im Login-Eintrag, und lassen Sie Row Level Security sie durchsetzen. Eine Spalte wie role in profiles genügt für eine Organisation. Kann eine Person mehreren Firmen oder Workspaces angehören, nehmen Sie stattdessen eine Tabelle memberships (Nutzer, Organisation, Rolle), damit dieselbe Person in der einen Admin und in der anderen Kunde sein kann.

Einen Menüpunkt für Kunden auszublenden ist keine Sicherheit: Die Datenbank muss die Anfrage ablehnen. Eine Policy wie „Ein Kunde darf nur die Rechnungen lesen, bei denen client_id zu seiner eigenen Mitgliedschaft passt“ leistet das. Lassen Sie Nutzer niemals ihre eigene Rollenspalte ändern; die Policy auf profiles sollte das Ändern von Name und Avatar erlauben, aber nicht der Rolle.

Registrierung nur per Einladung für interne Tools und Portale

Für ein internes Tool oder ein Kundenportal schalten Sie die offene Registrierung ab und legen Konten nur auf Einladung an. Supabase hat dafür die Einstellung „Allow new users to sign up“; ist sie deaktiviert, können sich nur bestehende Nutzer anmelden. Die Einladung selbst, die den Nutzer anlegt, die Rolle zuweist und die E-Mail verschickt, muss auf dem Server laufen, in einer Edge Function, denn sie braucht einen geheimen Schlüssel, der nie in den Browser gelangen darf.

Der Ablauf, den Sie anfordern: Ein Admin gibt eine E-Mail-Adresse und eine Rolle ein, der Server legt den Nutzer und die Mitgliedschaftszeile an, und die eingeladene Person erhält einen Link, um ein Passwort festzulegen. Unsere Leitfäden zu internen Tools und Kundenportalen zeigen, wo das in einer vollständigen App steht.

Site URL und Redirect-URLs

Die Site URL ist die Standardadresse, zu der Supabase Nutzer zurückschickt, und die Redirect-URLs sind eine Positivliste weiterer erlaubter Adressen. Laut der Dokumentation zu Redirect-URLs steht die Site URL anfangs auf http://localhost:3000 und muss auf Ihre Produktionsadresse geändert werden, weil E-Mail-Bestätigungen und Passwort-Resets davon abhängen.

Tragen Sie jede echte Adresse ein, unter der Ihre App erreichbar ist: Ihre Produktionsdomain, Ihre eigene Domain, falls vorhanden, und jede Vorschauadresse, auf der Sie testen. Die Dokumentation empfiehlt in der Produktion exakte Pfade und Platzhalter vor allem für lokale Entwicklung und Vorschauen. Der klassische Fehler ist eine veröffentlichte App, deren E-Mails weiter auf localhost zeigen, oder eine später hinzugefügte eigene Domain, die nie eingetragen wurde.

E-Mail-Limits und eigenes SMTP

Der eingebaute Mailer von Supabase ist nur zum Testen gedacht: Laut Dokumentation (Stand November 2026) ist er auf 2 Nachrichten pro Stunde begrenzt, liefert nur an Adressen aus dem Team Ihrer Organisation und bietet keine Zustellgarantie. Diese Zahlen können sich ohne Vorankündigung ändern, lesen Sie deshalb vor dem Start die Seite zu eigenem SMTP.

Binden Sie vor den ersten echten Nutzern einen eigenen Anbieter an (die Seite nennt Resend, AWS SES, Postmark, SendGrid, ZeptoMail und Brevo als Beispiele). Dieselbe Seite vermerkt, dass eigenes SMTP bei 30 Nachrichten pro Stunde beginnt, auf der Seite zu den Rate Limits anpassbar, und empfiehlt, Ihre Absenderdomain mit DKIM, SPF und DMARC zu authentifizieren. Erhält Ihr erster Testnutzer die Bestätigungs-E-Mail nie, ist das der Grund und kein Fehler Ihrer App.

Wie Cadrant es einrichtet

Cadrant, unser Baukasten, nutzt Supabase Auth in einem Supabase-Projekt, das zu Ihrem eigenen Supabase-Konto gehört, die Nutzerkonten bleiben also Ihre. Laut unserer Dokumentation zur Authentifizierung erzeugt er die Login- und Registrierungsseiten, richtet die Registrierung per E-Mail und Passwort ein, schützt die Routen, die eine Session brauchen, und verwaltet die Sessions. OAuth-Anbieter wie Google aktivieren Sie selbst im Supabase-Dashboard unter Authentication, Providers.

Die KI schreibt die Migrationen mit Row Level Security auf Tabellen mit Nutzerbezug und kann das aktuelle Schema und die Policies lesen, bevor sie etwas ändert. Rollen beschreiben Sie im Prompt, sie werden in Spalten oder Tabellen Ihrer Datenbank gespeichert. Geheimnisse wie der Schlüssel eines E-Mail-Anbieters bleiben in Umgebungsvariablen hinter Edge Functions. Was Sie wissen sollten: Site URL, Redirect-URLs, Zugangsdaten der Anbieter und eigenes SMTP sind Supabase-Einstellungen, die Sie selbst prüfen, und Sie sollten jede Rolle von Hand testen, bevor Sie Kunden einladen. Siehe auch unsere Übersicht zu Supabase mit einem KI-App-Baukasten.

Prompt-Sätze zum Einfügen in Ihren KI-App-Baukasten

Beschreiben Sie die Personen und die Regeln, nicht den Code. Diese Sätze funktionieren in den meisten Baukästen:

• „Baue einen Login mit E-Mail und Passwort sowie mit Google ein. Nutzer müssen ihre E-Mail bestätigen, bevor sie sich anmelden.“
• „Lege eine Tabelle profiles an, verknüpft mit den Auth-Nutzern und bei der Registrierung automatisch befüllt, mit einer Spalte role (admin, member, client). Nutzer können ihren Namen ändern, nie ihre Rolle.“
• „Die Registrierung ist geschlossen. Nur ein Admin kann per E-Mail einen Nutzer einladen und dessen Rolle festlegen, über eine serverseitige Funktion.“
• „Ein Kunde sieht nur seine eigenen Datensätze. Ein Mitglied sieht das ganze Team. Ein Admin sieht alles und verwaltet die Nutzer. Setze das mit Row Level Security durch, nicht nur in der Oberfläche.“
• „Füge einen Link ‚Passwort vergessen‘ und eine Seite zum Festlegen eines neuen Passworts hinzu. Leite abgemeldete Nutzer auf die Login-Seite um.“

Welche Konfiguration für welchen Fall