Auth0 verlassen: was wirklich umzieht, und das eine, das sie nicht herausrücken

Die meisten Teams verlassen Auth0 nicht, weil sie es nicht mögen. Sie gehen, weil die Rechnung sprunghaft gestiegen ist, oder weil sich herausstellte, dass SAML und SCIM hinter einer Enterprise-Stufe pro Verbindung liegen und der SSO-Link jedes neuen Kunden den Zähler weiter hochtreibt. Dann sehen sie sich an, was es heißt, ihren Identitätsanbieter tatsächlich zu migrieren, befinden es für furchteinflößend und bleiben noch ein Jahr.

Es ist weniger furchteinflößend, als es aussieht. Hier ist, was eine echte Auth0-Migration umfasst: die langweiligen Teile, die kniffligen Teile und der eine wirklich harte Teil, damit Sie es selbst beurteilen können.

Was in Ihrem Auth0-Tenant steckt

Eine Handvoll Dinge müssen an einem neuen Ort landen:

• Applications → OAuth/OIDC-Clients. Callbacks, Logout-URLs, erlaubte Origins, Grant-Typen und das Client-Secret. Mechanisch.
• APIs (Resource Server) + Scopes → Audiences und Scopes, verdrahtet mit den Clients, die sie nutzen (Auth0 verfolgt das als "Client Grants").
• Rollen und ihre Zuweisungen → Rollen + Rollenverknüpfungen pro Nutzer.
• Connections → Enterprise- (OIDC/SAML), Social- und Datenbank-Connections. Enterprise-OIDC bildet sich sauber auf einen föderierten Anbieter ab; den Rest konfigurieren Sie neu.
• Users → Profile, Metadaten und verknüpfte Social-/Enterprise-Identitäten.

Nichts davon ist im Prinzip schwer. Die Nervosität kommt von drei konkreten Dingen.

Die drei Dinge, die Menschen nervös machen

1. Identitäten stabil halten. Ihre Nutzer werden überall über ihren sub referenziert (und Ihre Apps über client_id): Refresh-Tokens, die nachgelagerte Apps halten, SCIM-Zeilen in den IdPs Ihrer Kunden, Nutzer-IDs in Ihrer eigenen Datenbank. Wenn eine Migration neue IDs prägt, bricht all das stillschweigend. Die Lösung ist einfach zu benennen und essenziell, richtig zu machen: die Auth0-user_id als sub bewahren und die client_id wortwörtlich beibehalten. Dann bemerkt nichts Nachgelagertes etwas.

2. Passwörter, das wirklich harte Thema. Auth0s Management-API gibt Passwort-Hashes niemals zurück. Das ist eine bewusste Auth0-Richtlinie, keine Lücke in Ihrem Werkzeug. Sie haben zwei ehrliche Wege:

• Fordern Sie Auth0s support-gestützten Massenexport an, der Ihnen eine NDJSON-Datei mit dem bcrypt-Hash jedes Nutzers liefert. Bcrypt ist portabel: Alles, was bcrypt verifiziert, kann diese Hashes wortwörtlich übernehmen, und Ihre Nutzer setzen nichts zurück.
• Oder verzichten Sie ganz auf Hashes und lassen Sie Nutzer beim ersten Anmelden ein neues Passwort setzen. Nichts geht "verloren" (es gab keinen Hash mitzunehmen), aber es ist ein sichtbarer Schritt für Ihre Nutzer.

Es gibt keine Self-Service-API für die Hashes. Wer Ihnen erzählt, ein Ein-Klick-Auth0-Export enthalte Passwörter ohne diese Support-Datei, schwafelt.

3. Die 1.000-Nutzer-Grenze. Auth0s API zum Auflisten von Nutzern gibt höchstens 1.000 Nutzer zurück. Für einen größeren Tenant ist die Massenexport-Datei (dieselbe, die die Hashes trägt) die echte, vollständige Nutzerquelle, nicht die Live-API.

Ein-Klick machen

Genau das haben wir in Authagonal eingebaut. Sie richten den Importer auf eine Auth0-Machine-to-Machine-App (nur Lese-Scopes), und er:

• Führt zuerst eine schreibgeschützte Vorschau aus: Er zählt jede Application, API, Rolle, Connection und jeden Nutzer, die er importieren wird, und markiert alles, was Aufmerksamkeit braucht. Es wird nichts geschrieben, bis Sie bestätigen.
• Bringt Applications, API-Scopes/-Audiences, Rollen + Zuweisungen, Nutzer + Metadaten und Enterprise-OIDC-Connections herüber, wobei sub und client_id bewahrt werden, sodass bestehende Tokens und Referenzen weiter auflösen.
• Re-hasht Auth0s (im Klartext lesbare) Client-Secrets, damit sich Ihre Apps ohne Rotation weiter authentifizieren.
• Importiert bcrypt-Passwort-Hashes wortwörtlich, wenn Sie die Exportdatei liefern, und dieselbe Datei hebt auch die 1.000-Nutzer-Grenze auf. Kein Export? Nutzer setzen beim ersten Anmelden ein Passwort.

Und weil die Enterprise-Funktionen (SAML, SCIM, MFA, Audit-Logs, eigene Domains) in jedem Tarif enthalten sind, statt pro Verbindung abgerechnet zu werden, wartet das, was Sie zum Ausgang drängte, auf der anderen Seite nicht auf Sie.

Eine Randbemerkung zum Testen von Migrationen

Wir testen den Importer gegen eine echte, mit Daten befüllte Datenbank, nicht gegen Mocks, und das hat sich ausgezahlt. ASP.NET Identity speichert LockoutEnd als datetimeoffset, und das Lesen mit GetDateTime() wirft bei diesem Typ eine Ausnahme. Ein einziger gesperrter Nutzer hätte einen ganzen Import scheitern lassen. So etwas fängt man nur ab, indem man den echten Importer gegen echte Daten laufen lässt. Wenn Sie ein Migrationswerkzeug bewerten, fragen Sie, wie es getestet wird: "Wir mocken die Quell-API" ist nicht dasselbe wie "Wir lassen es gegen einen befüllten Tenant laufen".

Wenn Sie zum Ausgang schielen

Die Migration ist langweiliger, als Sie befürchten: Vorschau ansehen, IDs behalten, Ihren Passwort-Weg entscheiden, wobei die eine echte Einschränkung Auth0s Hash-Export ist. Wenn Sie sehen wollen, was aus Ihrem Tenant herüberkäme, ist die Vorschau schreibgeschützt und zeigt Ihnen alles, bevor Sie bestätigen.

→ Von Auth0 migrieren