Was ist der Unterschied zwischen Authentifizierung und Multi-Tenancy?

Authentifizierung beantwortet "Wer bist du?", Multi-Tenancy beantwortet "Auf wessen Daten darfst du zugreifen?". Du kannst eine App haben, bei der jeder Nutzer sich korrekt authentifiziert, aber alle Nutzerdaten in derselben Tabelle ohne Isolation liegen — das ist keine Multi-Tenancy. Supabase RLS erzwingt die Datenisolierung auf Datenbankebene und stellt sicher, dass Nutzer A niemals Daten von Nutzer B sehen kann.

Kann Supabase RLS die DSGVO-Anforderung zur Datentrennung erfüllen?

Ja. RLS erzwingt Datenisolierung auf Datenbankebene — selbst wenn ein Bug in deiner Anwendungslogik keine workspace_id-Filter anwendet, gibt die Datenbank niemals Daten eines anderen Tenants zurück. Für deutsche B2B-Kunden mit Datenschutzbeauftragtem ist das ein starkes Privacy-by-Design-Argument und dokumentierbar in deinem DSGVO-Verarbeitungsverzeichnis.

Wie handhabt man einen Nutzer, der zu mehreren Workspaces gehört?

Speichere die "aktive" workspace_id in der Browser-Sitzung des Nutzers. Wenn ein Nutzer den Workspace wechselt, erneuere das Supabase-JWT-Token mit der neuen workspace_id — alle nachfolgenden Queries werden automatisch für den neuen Workspace gefiltert. In WeWeb ist der Workspace-Wechsel eine einzige Auth-Aktion, die den Token erneuert und alle gebundenen Daten neu lädt.

Wie viel Performance-Overhead verursacht RLS bei jeder Query?

Der Overhead von Supabase RLS ist minimal — typischerweise unter 1 ms pro Query für einfache Policies. Da die Policy-Evaluation direkt in PostgreSQL stattfindet, ohne zusätzliche Netzwerk-Roundtrips, ist es effizienter als anwendungsseitige Filterung. Für komplexe Policies mit mehreren Joins empfehlen wir, die Execution Plans zu prüfen und ggf. Indizes auf workspace_id-Spalten zu optimieren.

Multi-Tenancy mit WeWeb: SaaS für mehrere Kunden bauen

Was Multi-Tenancy wirklich bedeutet

Multi-Tenancy ist nicht nur "verschiedene Nutzer". Es ist die Garantie, dass Firma A niemals Daten von Firma B sehen, bearbeiten oder löschen kann — auch nicht durch einen Bug in deinem Anwendungscode.

Das klingt selbstverständlich, aber viele SaaS-Teams implementieren Datentrennung auf Anwendungsebene: "Zeige nur Datensätze, bei denen company_id = aktuelle_firma". Das ist anfällig. Ein Logikfehler, und Kundendaten lecken.

Supabase Row Level Security löst das auf Datenbankebene. Egal was dein WeWeb-Frontend oder Xano-Backend sendet — die Datenbank erzwingt die Isolation. Das ist Multi-Tenancy, auf die man sich verlassen kann, und für deutsche B2B-Kunden mit Datenschutzbeauftragtem ist es die einzig akzeptable Implementierung.

Datenbankstruktur für Multi-Tenancy

Jede Tabelle, die tenantspezifische Daten enthält, bekommt eine workspace_id-Spalte:

ALTER TABLE projects ADD COLUMN workspace_id uuid REFERENCES workspaces(id);

Die workspaces-Tabelle enthält einen Eintrag pro Kunde. Die workspace_members-Tabelle verbindet Nutzer mit Workspaces und enthält eine Rollenspalte (owner, admin, member).

Dieses Schema gilt für jede Tabelle in deiner App: Dokumente, Kommentare, Einstellungen, Dateien — alles bekommt workspace_id. Es fühlt sich wiederholend an, ist aber nicht verhandelbar. Wenn du es bei einer Tabelle vergisst, hast du eine Datenleck-Schwachstelle.

RLS-Policies einrichten

In Supabase aktivierst du RLS für jede Tabelle und erstellst Policies:

ALTER TABLE projects ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users can only access their workspace projects" ON projects FOR ALL USING (workspace_id = (auth.jwt() ->> 'workspace_id')::uuid);

Das ist es. Supabase überprüft automatisch diese Policy bei jeder Query. Ein Nutzer von Acme GmbH kann niemals auf Projekte von Müller Consulting zugreifen — selbst wenn er direkt die Supabase-API aufruft.

Für Insert-Policies füge eine WITH CHECK-Klausel hinzu, die sicherstellt, dass neue Datensätze immer die richtige workspace_id erhalten. Das verhindert, dass Nutzer absichtlich oder versehentlich Daten im falschen Workspace erstellen.

JWT Claims konfigurieren

Supabase muss die workspace_id des aktuellen Nutzers in seinem JWT-Token kennen. Das erreichst du mit einer benutzerdefinierten Supabase Edge Function, die nach dem Login ausgeführt wird und workspace_id dem JWT-Token hinzufügt.

In WeWeb greifst du auf diese Claims über den integrierten Auth-Plugin zu. Wenn ein Nutzer sich einloggt, enthält sein Token automatisch seine workspace_id — und Supabase RLS filtert alle Queries entsprechend.

Für Nutzer, die zu mehreren Workspaces gehören, speichere den "aktiven" Workspace in der Browser-Sitzung. Wenn ein Nutzer den Workspace wechselt, erneuere das Token mit der neuen workspace_id. WeWebs Sitzungsverwaltung macht das mit einer einzigen Aktion möglich.

Rollenbasierte Zugriffskontrolle in WeWeb

Über die Workspace-Isolation hinaus benötigst du feingranulare Rollenkontrolle. In WeWeb verwendest du bedingte Sichtbarkeit basierend auf der Nutzerrolle, die aus dem JWT-Token gelesen wird.

Für UI-Elemente: Blende Admin-Buttons aus, wenn die Rolle nicht "admin" oder "owner" ist. Für Datenbankzugriffe: Erstelle separate RLS-Policies für Lesen vs. Schreiben basierend auf der Rolle.

Ein häufiges Muster für Mittelstandskunden: "Owner" kann Nutzer einladen und abrechnen, "Admin" kann Einstellungen ändern und alle Daten sehen, "Member" kann nur eigene Daten lesen und schreiben. Dieses dreistufige Modell deckt 90 % der deutschen B2B-SaaS-Anforderungen ab.

Testen und Absichern der Isolation

Teste Multi-Tenancy mit mindestens zwei Test-Workspaces. Versuche manuell, mit einem Nutzer von Workspace A auf Daten von Workspace B zuzugreifen — direkt über die Supabase-API. Mit korrekten RLS-Policies sollte das eine leere Menge oder einen Fehler zurückgeben, niemals Daten.

Führe diesen Test durch: Erstelle Datensätze in Workspace A. Melde dich mit einem Nutzer von Workspace B an. Sende eine direkte Supabase-Abfrage ohne workspace_id Filter. Ergebnis: leere Menge. Das ist der Beweis, dass deine RLS korrekt funktioniert.

Für App Studio ist das ein Pflichtbestandteil unserer QA-Checkliste für jede SaaS, die wir bauen. Unsere <a href="/compare/weweb-vs-bubble">50+ Produktions-Apps</a> werden alle mit diesem Sicherheitsstandard geliefert.

Onboarding für neue Workspaces

Wenn ein neuer Kunde sich anmeldet, musst du automatisch: einen Workspace erstellen, den Gründer als "owner" hinzufügen, Standard-Einstellungen anlegen und die erste Stripe-Subscription verknüpfen.

In Xano erstellst du einen "Create Workspace"-Endpoint, der alle diese Schritte in einer atomaren Transaktion ausführt. WeWeb ruft diesen Endpoint nach der E-Mail-Verifikation auf.

Für deutsche B2B-Kunden füge zu diesem Onboarding-Flow hinzu: Unternehmensname und USt-ID-Eingabe (für korrekte Rechnungsstellung), Datenschutzerklärung-Zustimmung mit Zeitstempel (DSGVO-Anforderung) und ggf. die Verarbeitung eines SEPA-Lastschrift-Mandats über Stripe.