Eine Identity-Migration betrifft jeden aktiven Nutzer und sollte vorab vollständig getestet werden. WZ-IT bietet die Supabase-Migration ab 3.490 € nach Prüfung von Auth0-Tenant, Anwendungen und Login-Verfahren an.
Eine Migration von Auth0 zu Supabase Auth überträgt nicht nur Nutzerprofile. Passwörter, Social Identities, MFA, SSO, Rollen, Claims, Sessions und die Anwendungsintegration greifen ineinander. Ein fehlerhafter Cutover kann Nutzer aussperren oder Berechtigungen verändern.
Die Migrationsstrategie wird deshalb aus den tatsächlich verwendeten Login-Verfahren abgeleitet.
Auth0-Bestand aufnehmen
Vor der technischen Umsetzung werden erfasst:
- Datenbankverbindungen und Passwort-Login
- Social und Enterprise Identity Provider
- Passwordless per E-Mail oder Telefon
- MFA-Faktoren und Recovery-Prozesse
- SAML- oder OIDC-Verbindungen
- Auth0 Organizations, Rollen und Permissions
- Rules, Actions, Hooks und eigene Claims
- Universal Login und eigene Login-Oberflächen
- Anwendungen, APIs, Audiences und Callback-URLs
- Nutzerzahl, aktive Konten und Anmeldehäufigkeit
- Anforderungen an Downtime und Rückfall
Nicht jedes Auth0-Feature besitzt eine identische Supabase-Entsprechung. Vor der Migration entsteht deshalb eine Feature-Matrix mit „direkt abbildbar“, „anzupassen“ und „neu zu entwickeln“.
Nutzer- und Berechtigungsmodell abbilden
| Auth0 | Supabase-Ziel |
|---|---|
| User Profile | auth.users und bei Bedarf eigene Profiltabelle |
user_metadata |
raw_user_meta_data für nicht sensible Nutzerdaten |
app_metadata |
raw_app_meta_data oder private Tabellen |
| Rollen und Permissions | Claims, Profiltabellen und RLS-Policies |
| Social Identity | Supabase OAuth Provider und auth.identities |
| Actions/Rules | Hooks, Functions oder Anwendungslogik |
| Organizations | eigenes Mandantenmodell mit Mitgliedschaften und RLS |
Umfangreiche oder sensible Berechtigungsdaten gehören nicht pauschal in JWT-Metadata. Ein relationales Modell in einem privaten Schema ist oft besser prüfbar.
Export aus Auth0
Die offizielle Supabase-Anleitung nennt zwei Wege für Nutzerdaten:
- Auth0 Data Export
- Auth0 Management API mit Rate Limits und gegebenenfalls Batches
Für Passwort-Hashes und MFA-Faktoren verweist Supabase auf den Auth0-Support. Dieser Schritt muss früh geklärt werden, weil er bestimmt, ob Passwörter erhalten bleiben oder ein Reset-/Fallback-Prozess nötig wird.
Supabase Auth unterstützt laut aktueller Dokumentation bcrypt- und Argon2-Passwort-Hashes. Hash-Algorithmus, Parameter und Zuordnung der Auth0-ID werden vor dem Import geprüft.
One-off oder Rolling Migration
Einmaliger Cutover
Alle übertragbaren Konten werden vorbereitet und zu einem definierten Zeitpunkt importiert. Anschließend wechselt die Anwendung vollständig zu Supabase Auth.
Vorteile:
- nur ein Auth-System nach dem Cutover
- klare technische Trennung
Nachteile:
- höheres Risiko in einem kurzen Zeitfenster
- Nutzer müssen sich neu anmelden
- nicht importierbare Konten benötigen einen Reset- oder Supportweg
Rolling Migration
Neue Nutzer verwenden bereits Supabase. Bestehende Nutzer werden beim nächsten erfolgreichen Auth0-Login nach Supabase übernommen oder vorab importiert. Die offizielle Anleitung beschreibt einen Fallback: zuerst Supabase testen, dann Auth0 und bei Erfolg das Konto in Supabase anlegen.
Vorteile:
- Übergang verteilt sich über aktive Nutzer
- kein einmaliger harter Wechsel für alle Konten
Nachteile:
- zwei Auth-Pfade müssen vorübergehend sicher betrieben werden
- inaktive Nutzer benötigen später einen Backfill oder Reset
- Autorisierung muss in beiden Pfaden konsistent bleiben
Passwort, Passwordless und OAuth getrennt behandeln
Passwortkonten: Hashes importieren, sofern Export und Algorithmus passen. Sonst Reset oder Rolling Fallback planen.
Passwordless: Bestätigte E-Mail- oder Telefonnummern übernehmen und Templates, SMTP sowie OTP-Flows in Supabase neu konfigurieren.
Social OAuth: Provider und Callback-URLs in Supabase einrichten. Nutzer melden sich erneut beim Provider an; Provider-ID und bestehendes internes Profil werden anschließend zugeordnet.
Diese Gruppen benötigen getrennte Testfälle und dürfen nicht als ein einheitlicher Nutzerexport behandelt werden.
MFA, SSO und Organisationen
MFA-Faktoren, SAML-Verbindungen und Auth0 Organizations sind die typischen Scope-Treiber. Zu prüfen sind:
- unterstützte MFA-Verfahren und notwendige Neueinrichtung
- Enterprise-SSO je Kundendomäne
- SAML-Metadaten, Zertifikate und Callback-URLs
- Mandanten, Mitgliedschaften und Einladungen
- Rollen je Organisation und globale Rollen
- Mapping auf RLS und serverseitige Autorisierung
Ein Produkt mit B2B-Mandanten braucht meist ein eigenes Organisationsmodell über der reinen Auth-Nutzertabelle.
Anwendung, JWT und RLS umstellen
Die Anwendung erhält neue:
- SDK-Aufrufe und Sessionverwaltung
- Access- und Refresh-Token
- JWT-Claims und Ablaufzeiten
- Callback-, Logout- und Redirect-URLs
- E-Mail-Templates und SMTP-Einstellungen
- serverseitige Schlüssel und API-Prüfungen
Bestehende Auth0-Tokens bleiben keine Supabase-Sessions. APIs müssen während der Rolling-Phase gegebenenfalls beide Issuer kontrolliert unterstützen. Nach dem Übergang werden alte Pfade entfernt.
Rollen und Mandantenzugriffe werden mit positiven und negativen RLS-Tests abgenommen. Die Anleitung Supabase RLS prüfen zeigt den dafür notwendigen Prüfrahmen.
Abnahme und Rückfall
Getestet werden mindestens:
- Passwort, Passwordless und jeder OAuth-Provider
- neue und migrierte Nutzer
- E-Mail-Verifikation und Passwort-Reset
- MFA und SSO, soweit im Scope
- Rollen, Claims und Mandantentrennung
- Token Refresh, Logout und Sessionablauf
- deaktivierte, gesperrte und doppelte Konten
- Supportweg für nicht migrierbare Nutzer
Auth0 wird erst abgeschaltet, wenn aktive Login-Wege stabil sind und der Rückfallzeitraum beendet ist. Der Gesamtprozess folgt der Supabase-Migrationscheckliste.
WZ-IT kann Supabase Auth anschließend innerhalb des Managed-Supabase-Betriebs betreuen.
