Skip to content
Innopulse Consulting
SaaS bauen

Authentication in modernem SaaS: Supabase Auth vs. Better Auth vs. Clerk

Drei Auth-Optionen für Next.js-SaaS im Vergleich: Supabase Auth (gratis, integriert), Better Auth (Self-Hosted), Clerk (Managed, teurer). Ehrlicher Tradeoff.

Leutrim Miftaraj
Leutrim Miftaraj
Gründer & CEO
·7 min Lesezeit

Authentifizierung ist der Teil eines SaaS-Produkts, den Kunden nie loben und bei dem jeder Fehler teuer ist. Die Entscheidung zwischen einer integrierten Lösung, einem selbst betriebenen Baukasten und einem verwalteten Dienst fällt deshalb selten über Funktionen, sondern über die Frage, wo die Nutzerdaten liegen sollen und wie stark man sich binden will.

Der Punkt, der die Wahl bestimmt: wo liegen die Nutzerdaten

Bei einer in die Datenbank integrierten Lösung liegen die Konten in derselben Datenbank wie die übrigen Daten. Das erlaubt Fremdschlüssel auf die Nutzertabelle, Zugriffsregeln, die sich direkt darauf stützen, und einen Export ohne Umweg.

Bei einem externen verwalteten Dienst liegen sie beim Anbieter. Das Produkt hält eine Kopie oder eine Referenz, und jede Abfrage, die Nutzerdaten mit Fachdaten verbindet, braucht eine Synchronisation.

Diese Synchronisation ist die Stelle, an der solche Aufbauten in der Praxis brechen: Ein Konto wird beim Anbieter gelöscht, die lokale Kopie bleibt, und irgendwo hängt eine Referenz ins Leere. Es ist lösbar, aber es ist dauerhafte Arbeit.

Was für die integrierte Lösung spricht

Wer bereits eine Plattform nutzt, die Authentifizierung mitbringt, bekommt Zugriffsregeln, die sich unmittelbar auf die angemeldete Person stützen, ohne dass ein Token durch mehrere Schichten gereicht werden muss.

Für mandantenfähige Anwendungen mit Zeilensicherheit ist das ein erheblicher Vorteil: Die Identität ist dort verfügbar, wo die Regel ausgewertet wird. Bei einem externen Anbieter muss diese Verbindung selbst hergestellt werden.

Die Grenze liegt bei Anforderungen, die über den Standard hinausgehen — Anmeldung über die Identitätsverwaltung des Kunden, feingranulare Organisationsstrukturen, Zertifizierungen, die der Einkauf verlangt.

Was für einen verwalteten Dienst spricht

Verwaltete Anbieter nehmen Arbeit ab, die man unterschätzt: fertige Oberflächen für Anmeldung und Registrierung, Verwaltung von Organisationen und Einladungen, Mehrfaktor-Authentifizierung, Erkennung verdächtiger Anmeldungen.

Der entscheidende Punkt kommt aber später: Sobald Geschäftskunden die Anbindung an ihre eigene Identitätsverwaltung verlangen, ist das mit einem verwalteten Anbieter eine Konfiguration und in Eigenbau ein Projekt. Wer diesen Kundentyp anstrebt, sollte das früh einrechnen.

Gegen den Dienst sprechen die nutzungsabhängigen Kosten, die mit dem Erfolg wachsen, und die Bindung an einen weiteren Anbieter — auch datenschutzrechtlich, weil Konten personenbezogene Daten sind und der Anbieter damit in die Auftragsverarbeitungskette gehört.

Selbst bauen

Ein selbst betriebener Baukasten ist ein Mittelweg: volle Kontrolle über die Daten, keine nutzungsabhängigen Kosten, aber auch die Verantwortung für Aktualisierungen, Fehlerbehebung und den Betrieb.

Vertretbar ist das, wenn im Team jemand ist, der sich mit den Grundlagen tatsächlich auskennt. Nicht vertretbar ist, die Kernbestandteile selbst zu implementieren — Passwortspeicherung, Sitzungsverwaltung, Zurücksetzen von Kennwörtern. Das sind gelöste Probleme, bei denen jeder Eigenbau eine neue Angriffsfläche schafft.

Die Anforderung, die alles verschiebt

Sobald ein Kunde die Anmeldung über die eigene Identitätsverwaltung verlangt, ändert sich die Rechnung. Das ist im deutschsprachigen Geschäftskundenumfeld ab einer bestimmten Kundengrösse Standard und taucht regelmässig im Sicherheitsfragebogen auf, bevor über den Vertrag gesprochen wird.

Es lohnt sich, diese Frage vor der Wahl zu stellen: Ist das ein Kundenkreis, den wir anstreben. Wenn ja, wird die Antwort darauf teurer als jede andere Eigenschaft.

Was in jedem Fall selbst zu bauen ist

Unabhängig von der Wahl bleiben drei Dinge Ihre Aufgabe. Erstens die Autorisierung: Wer angemeldet ist, ist nicht automatisch berechtigt. Die Prüfung, ob diese Person auf diese Ressource zugreifen darf, gehört in Ihre Anwendung.

Zweitens die Zuordnung von Konten zu Mandanten und Rollen. Kein Anbieter kennt Ihr Berechtigungsmodell.

Drittens die vollständige Löschung eines Kontos über alle Systeme hinweg. Bei einem externen Anbieter bedeutet das zwei Löschvorgänge, und beide müssen zuverlässig sein.

Über den Autor
Leutrim Miftaraj
Leutrim Miftaraj
Gründer & CEO · Innopulse Consulting

Gründer und leitender Ingenieur von Innopulse Consulting. MSc Innovation Management (FFHS). Autor von „Identity Over Discipline".

Topics
saas authenticationsupabase authbetter authclerk
Arbeiten Sie an etwas Ähnlichem?

Sprechen wir.

Wenn dieser Artikel ein Problem trifft, an dem Sie gerade arbeiten, schicken Sie uns eine kurze Beschreibung — wir antworten mit einem konkreten nächsten Schritt.