Auth0 zu Supabase Auth migrieren: Nutzer, Passwörter und Login

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

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.

Quellen

• Supabase: Migrate from Auth0 to Supabase Auth
• Auth0: Export user data
• Supabase Auth: Users