Reicht Supabase Auth? Wann du Keycloak brauchst – und wann nicht

Die Frage fällt in fast jedem Projektgespräch, sobald Supabase gesetzt ist: «Brauchen wir dann überhaupt noch Keycloak?» Meine Antwort überrascht viele: in der Mehrzahl der Fälle nein. Und das sage ich als jemand, der mit dem Aufsetzen und Betreiben von Keycloak Geld verdient.

Zur Einordnung, wer hier schreibt: Ich bin Matthias, Ein-Personen-Agentur happycoding.agency in Berlin. Ich setze beide Systeme produktiv ein und habe mit keinem Anbieter einen Vertrag: Was du hier liest, ist Projekterfahrung, keine Verkaufsargumentation.

Gerade deshalb rate ich dir ab, wenn der Bedarf fehlt. Ein Identity-Server ohne Auftrag ist keine Investition, sondern laufender Aufwand ohne Gegenwert: Er will gepatcht, überwacht und bei jedem Major-Release angefasst werden, während deine Nutzer schlicht einen funktionierenden Login wollen.

In diesem Artikel ziehe ich die Grenze so präzise, wie meine Projekterfahrung es hergibt: zuerst das, was Supabase Auth wirklich kann, dann die vier Punkte, an denen es endet. Dazu eine Entscheidungsmatrix und ein beruhigender Befund zum Schluss: Falls du später wechseln musst, sitzt du nicht in der Falle.

Vorab die Einordnung: Supabase Auth ist kein Zusatzmodul, sondern fester Bestandteil jedes Supabase-Projekts. Es gibt keinen zweiten Dienst, keine Token-Synchronisation zwischen Systemen, keine zusätzliche Rechnung. Der Pro-Plan kostet 25 $ im Monat und enthält 100.000 monatlich aktive Nutzer, kurz MAU (Quelle: Supabase-Preisseite, Stand: Oktober 2026).

Für die große Mehrheit der B2C- und SaaS-Anwendungen ist diese Liste vollständig. Registrierung, Session-Verwaltung und Token-Erneuerung laufen über dieselbe API, mit der du ohnehin arbeitest.

Der wichtigste Vorteil steht in keiner Feature-Tabelle: Auth und Datenbank sprechen dieselbe Sprache. In Row-Level-Security-Policies liest du mit auth.uid() die Nutzer-ID aus und mit auth.jwt() das komplette Token. Rollen und Rechte legst du in app_metadata ab, und die Autorisierung passiert in der Datenbank statt in jeder API-Route einzeln.

Ein Beispiel aus einem Kundenportal: Die Regel «Rechnungen sieht nur das eigene Unternehmen» ist eine Zeile SQL gegen auth.jwt(), kein Middleware-Stapel in drei Services.

Eine Falle dokumentiert Supabase selbst: user_metadata können Nutzer über die Update-Funktion eigenhändig beschreiben. Wer darauf Policies baut, verschenkt eine Rechteausweitung zum Selbstbedienungspreis. Merksatz: Autorisierungsdaten gehören ausnahmslos in app_metadata.

Hier räume ich mit einem veralteten Einwand auf. «Sobald der erste Enterprise-Kunde SAML verlangt, brauchst du Keycloak»: Das stimmt so nicht mehr. Supabase Auth unterstützt SAML 2.0 ab dem Pro-Plan, mit mehreren Identity-Providern parallel. Okta, Entra ID oder Google Workspace deiner Geschäftskunden lassen sich direkt anbinden.

Das typische Szenario: Du baust ein Portal für einen Mittelständler, dessen größter Abnehmer ein Konzern ist. Dessen IT-Abteilung verlangt, dass sich ihre Einkäufer über das hauseigene Okta anmelden. Früher begann an dieser Stelle das Keycloak-Projekt; heute ist es ein Konfigurationsschritt pro Kunde.

Ausweislich der Supabase-Preisseite (Stand: Oktober 2026) sind 50 SSO-MAU enthalten, danach kostet jeder aktive SSO-Nutzer 0,015 $ pro Monat. Ein B2B-Portal mit 500 SSO-Nutzern zahlt demnach rund 6,75 $ Aufpreis monatlich. Enterprise-SSO ist damit keine Budgetfrage mehr, sondern eine Architekturfrage.

Ehrlich bleiben heißt, auch die Kanten zu nennen: Single Logout fehlt, das Verknüpfen von SSO-Identitäten mit bestehenden Konten ist aus Sicherheitsgründen gesperrt, IdP-initiierte Flows vertragen sich nicht mit PKCE, und die Provider pflegst du per CLI. Für die meisten Projekte sind das Fußnoten. Was die beiden Protokolle grundsätzlich unterscheidet, liest du in SAML vs. OIDC.

Jetzt die andere Seite der Rechnung. Bei vier Anforderungen schwenke ich im Projektgespräch sofort Richtung Keycloak. Was Keycloak grundsätzlich ist und wie es arbeitet, erkläre ich im Keycloak-Grundlagenartikel; hier geht es allein um die Abgrenzung.

Sollen sich Mitarbeiter mit ihren bestehenden Verzeichniskonten anmelden, führt kein Weg an User-Federation vorbei. Keycloak bringt die Anbindung an LDAP- und Active-Directory-Server von Haus aus mit, samt Synchronisation von Gruppen und Attributen. Supabase Auth bietet hierfür nichts an: kein LDAP, keine Verzeichnis-Anbindung. In Konzern- und Behördenprojekten ist das regelmäßig das K.-o.-Kriterium.

Typischer Fall aus einer Anfrage: 400 Mitarbeiter, Gruppenrechte aus dem Active Directory, Passwort-Richtlinie der internen IT. Supabase Auth hat darauf keine Antwort, Keycloak löst es per Konfiguration.

Zur Ehrlichkeit gehört eine aktuelle Entwicklung: Supabase Auth kann mittlerweile selbst als Identity-Provider auftreten. Der eingebaute OAuth-2.1-Server stellt OIDC-Tokens für Drittanwendungen aus, ohne Aufpreis (Stand: Oktober 2026). Zwei Dinge kann er nicht: SAML-Assertions für fremde Systeme ausstellen und Mandanten sauber voneinander trennen.

Keycloak liefert beides, als SAML-IdP und mit getrennten Realms je Mandant. Realms sind dabei mehr als Namensräume: Jeder Mandant bekommt eigene Login-Maske, eigene Passwort-Richtlinien und eigene Administratoren. Wenn dein Produkt genau diese Trennung verkauft, ist das der Keycloak-Moment.

Supabase bietet sechs Auth Hooks, etwa für eigene JWT-Claims oder Prüfungen vor der Registrierung; die Hooks für MFA- und Passwort-Prüfungen gibt es erst ab dem Team-Plan. Das deckt viel ab, endet aber an festen Einhakpunkten. Keycloak lässt dich komplette Authentifizierungs-Flows zusammenstellen und per Code erweitern: verpflichtende Vertragsannahme vor dem ersten Login, Step-up-Prüfungen für heikle Aktionen, Abgleich mit Drittsystemen. Die Projektseite nennt das ausdrücklich «Customize through code».

Supabase läuft auf Wunsch in europäischen Regionen wie Frankfurt oder Zürich, und Self-Hosting per Docker existiert. Aber: Die Self-Hosting-Variante ist auf ein Einzelprojekt beschränkt, auf Community-Support angewiesen und um etliche Plattformfunktionen ärmer. Fordert dein Auftraggeber den Identity-Server vertraglich im eigenen Rechenzentrum, ist Keycloak die erwachsene Antwort: seit dem 10.04.2023 CNCF-Incubating-Projekt, betreibbar, wo du willst.

Der Unterschied liegt im Vertragswerk: Bei der Managed-Plattform bleibt Supabase dein Auftragsverarbeiter, auch wenn die Daten in Frankfurt liegen. Mit selbst betriebenem Keycloak gehört die Login-Infrastruktur dir, mitsamt Logs, Backups und Schlüsselmaterial. Manche Ausschreibung verlangt genau das, und dann hilft kein Preisargument.

Die vier Grenzen haben einen Preis, und der heißt Betrieb. Keycloak erscheint im Takt von vier Minor-Releases pro Jahr, Major-Versionen kommen alle zwei bis drei Jahre; aktuell ist 26.8.0 vom 01.10.2026 (Stand: Oktober 2026). Jedes Release will eingespielt, jede Konfiguration gesichert, jedes Upgrade getestet werden.

Dazu kommt die Team-Frage: Keycloak zu betreiben heißt, eine Java-Anwendung samt Datenbank und Cluster-Konfiguration zu verantworten. Das ist kein Hexenwerk, aber eine andere Disziplin als die Postgres-Welt, in der dein Supabase-Projekt bereits lebt.

Was das in Euro bedeutet, von der Einzelinstanz bis zum Betriebs-Retainer, habe ich im Artikel Was kostet Keycloak wirklich? ohne Zirka-Prosa aufgeschlüsselt. Die Kurzfassung: Die Lizenz kostet nichts, der Betrieb nie.

Zur Orientierung habe ich die häufigsten Konstellationen aus meinen Projektgesprächen verdichtet. Lies die Tabelle als Startpunkt, nicht als Urteil: Treffen zwei Zeilen gleichzeitig auf dich zu, gewinnt die strengere Anforderung.

Zwei Zeilen verdienen einen Kommentar. Erstens: «Firmenkunden verlangen SSO» ist kein Keycloak-Auslöser mehr, solange es um die Anmeldung in deiner eigenen App geht. Zweitens: Die letzte Zeile ist der Normalfall in meinen Projektgesprächen, und genau ihr gehört der folgende Abschnitt.

Das stärkste Argument für den Start mit Supabase Auth ist technisch, nicht preislich: Die Architektur hält dir die Tür offen. Supabase signiert Tokens auf Wunsch asymmetrisch mit ES256 oder RS256 und veröffentlicht die öffentlichen Schlüssel unter einem JWKS-Endpunkt. Externe Dienste prüfen deine Tokens, ohne dass du Geheimnisse teilen musst.

Umgekehrt akzeptiert Supabase auch fremde Tokens: Die Third-Party-Auth-Liste nennt offiziell Clerk, Firebase Auth, Auth0, AWS Cognito und WorkOS, abgerechnet mit 0,00325 $ pro Third-Party-MAU (Stand: Oktober 2026). Keycloak steht nicht auf dieser Liste, lässt sich aber als OAuth-Provider innerhalb von Supabase Auth anschließen; seit Keycloak 22 gehört dabei der openid-Scope in den Anmelde-Aufruf.

Wichtig für die Datenbank: Hängst du Keycloak als OAuth-Provider hinter Supabase Auth, stellt weiterhin Supabase die Tokens aus. Deine RLS-Policies mit auth.uid() und auth.jwt() bleiben unverändert gültig. Der Wechsel findet vor der Tür statt, nicht im Fundament.

Der realistische Pfad: Du startest mit Supabase Auth und RLS. Kommt in zwei Jahren die LDAP-Anforderung, stellst du Keycloak davor, statt Datenbank und Policies neu zu bauen. Welche Systeme dann neben Keycloak infrage kämen, habe ich im Vergleich der Keycloak-Alternativen durchgerechnet.

Du stehst gerade vor genau dieser Entscheidung? Dann prüfe drei Punkte deiner Anforderungsliste: Verzeichnis-Anbindung, SAML-Ausstellung, Betriebsort. Steht dort nichts davon, nimm Supabase Auth und investiere die gesparte Betriebszeit ins Produkt. Wie ich Supabase-Projekte aufsetze und betreue, zeigt dir meine Supabase-Leistungsseite.

Wenn du unsicher bist, welche Zeile der Matrix auf dich zutrifft: Schick mir deine Anforderungen, und ich sage dir in 30 Minuten ehrlich, ob Supabase Auth reicht. Zuweilen lautet die Antwort ja, obwohl ich mit Keycloak mehr verdienen würde: Buch dir ein unverbindliches Erstgespräch.