Om Auth0 te verlaat: wat werklik oortrek — en die een ding wat hulle nie sal oorhandig nie
Die meeste spanne verlaat Auth0 nie omdat hulle nie daarvan hou nie. Hulle vertrek omdat die rekening die hoogte ingeskiet het, of omdat SAML en SCIM uiteindelik agter ʼn ondernemingsvlak per verbinding skuil, en elke nuwe klant se SSO-skakel tel by die meter op. Dan kyk hulle na die werklike migrasie van hul identiteitsverskaffer, besluit dit klink skrikwekkend, en bly nog ʼn jaar.
Dit is minder skrikwekkend as wat dit lyk. Hier is wat ʼn werklike Auth0-migrasie behels — die vervelige dele, die lastige dele, en die een werklik moeilike deel — sodat jy self kan oordeel.
Wat in jou Auth0-tenant is
ʼn Handvol dinge moet êrens nuut beland:
- Toepassings → OAuth/OIDC-kliënte. Terugroepe, afmeld-URL's, toegelate oorspronge, toekenningstipes, en die kliëntgeheim. Meganies.
- API's (hulpbronbedieners) + scopes → audiences en scopes, gekoppel aan die kliënte wat hulle gebruik (Auth0 hou dit by as "client grants").
- Rolle en hul toewysings → rolle + rolskakels per gebruiker.
- Verbindings → onderneming (OIDC/SAML), sosiale, en databasisverbindings. Onderneming-OIDC karteer netjies na ʼn gefedereerde verskaffer; die res herkonfigureer jy.
- Gebruikers → profiele, metadata, en gekoppelde sosiale/onderneming-identiteite.
Niks daarvan is in beginsel moeilik nie. Die senuweeagtigheid kom van drie spesifieke dinge.
Die drie dinge wat mense senuweeagtig maak
1. Om identiteite stabiel te hou. Na jou gebruikers word oral verwys deur hul sub (en na jou toepassings deur client_id) — refresh tokens wat deur stroomaf-toepassings gehou word, SCIM-rye in klante se IdP's, gebruiker-ID's wat in jou eie databasis gestoor is. As ʼn migrasie nuwe ID's skep, breek dit alles stilweg. Die oplossing is eenvoudig om te stel en noodsaaklik om reg te kry: behou die Auth0 user_id as die sub en hou client_id woordeliks. Dan merk niks stroomaf dit op nie.
2. Wagwoorde — die werklik moeilike een. Auth0 se Management API gee nooit wagwoord-hashe terug nie. Dit is ʼn doelbewuste Auth0-beleid, nie ʼn leemte in jou gereedskap nie. Jy het twee eerlike paaie:
- Versoek Auth0 se ondersteuningsgesteunde grootmaat-uitvoer, wat jou ʼn NDJSON-lêer gee met elke gebruiker se bcrypt-hash. Bcrypt is oordraagbaar — enigiets wat bcrypt verifieer kan daardie hashe woordeliks neem, en jou gebruikers herstel nooit iets nie.
- Of slaan hashe heeltemal oor en laat gebruikers ʼn nuwe wagwoord stel met die eerste aanmelding. Niks gaan "verlore" nie — daar was geen hash om saam te dra nie — maar dit is ʼn sigbare stap vir jou gebruikers.
Daar is geen selfbedienings-API vir die hashe nie. Enigiemand wat vir jou sê ʼn een-klik Auth0-uitvoer sluit wagwoorde in sonder daardie ondersteuningslêer, praat in die wind.
3. Die plafon van 1 000 gebruikers. Auth0 se gebruiker-lysting-API gee hoogstens 1 000 gebruikers terug. Vir ʼn groter tenant is die grootmaat-uitvoerlêer (dieselfde een wat die hashe dra) die werklike, volledige bron van gebruikers — nie die lewendige API nie.
Om dit een klik te maak
Dit is wat ons in Authagonal gebou het. Jy rig die invoerder op ʼn Auth0 masjien-tot-masjien-toepassing (slegs lees-scopes), en dit:
- Loop eers ʼn leesalleen-voorskou — dit tel elke toepassing, API, rol, verbinding, en gebruiker wat dit gaan invoer en merk enigiets wat aandag verg. Niks word geskryf totdat jy dit bevestig nie.
- Bring toepassings, API-scopes/audiences, rolle + toewysings, gebruikers + metadata, en onderneming-OIDC-verbindings oor — met behoud van
subenclient_idsodat bestaande tokens en verwysings bly oplos. - Her-hash Auth0 se (skoonteks-by-lees) kliëntgeheime sodat jou toepassings sonder rotasie aanhou outentiseer.
- Voer bcrypt-wagwoord-hashe woordeliks in as jy die uitvoerlêer verskaf — en daardie lêer lig ook die plafon van 1 000 gebruikers op. Geen uitvoer nie? Gebruikers stel ʼn wagwoord met die eerste aanmelding.
En omdat die onderneming-kenmerke (SAML, SCIM, MFA, ouditlogboeke, pasgemaakte domeine) by elke plan ingesluit is eerder as om per verbinding gemeet te word, wag die ding wat jou na die uitgang gestoot het nie vir jou aan die ander kant nie.
ʼn Klein opmerking oor die toets van migrasies
Ons toets die invoerder teen ʼn werklike, gesaaide databasis, nie teen namaaksels nie — en dit het sy sout werd bewys. ASP.NET Identity stoor LockoutEnd as ʼn datetimeoffset, en om dit met GetDateTime() te lees, gooi ʼn fout op daardie tipe. ʼn Enkele uitgesluite gebruiker sou ʼn hele invoer laat misluk het. Jy vang dit net deur die werklike invoerder teen werklike data te laat loop. As jy enige migrasiegereedskap evalueer, vra hoe dit getoets word — "ons maak die bron-API na" is nie dieselfde as "ons laat dit teen ʼn bevolkte tenant loop" nie.
As jy na die uitgang loer
Die migrasie is veel verveliger as wat jy vrees — kry ʼn voorskou daarvan, hou jou ID's, besluit oor jou wagwoordpad — met die een werklike beperking wat Auth0 se hash-uitvoer is. As jy wil sien wat van jou tenant af sou oorkom, die voorskou is leesalleen en wys jou alles voordat jy dit bevestig.