Auth0 छोड़ना: असल में क्या माइग्रेट होता है, और वह एक चीज़ जो वे आपको नहीं देंगे

ज़्यादातर टीमें Auth0 इसलिए नहीं छोड़तीं कि उन्हें यह नापसंद है। वे इसलिए छोड़ती हैं क्योंकि बिल अचानक बढ़ गया, या क्योंकि पता चला कि SAML और SCIM एक per-connection एंटरप्राइज़ टियर के पीछे रहते हैं, और हर नए ग्राहक का SSO कनेक्शन मीटर पर जुड़ता जाता है। फिर वे अपने identity provider को असल में माइग्रेट करने की बात सोचते हैं, तय करते हैं कि यह डरावना लगता है, और एक साल और रुक जाते हैं।

यह जितना दिखता है, उतना डरावना नहीं है। यहाँ बताया गया है कि एक असली Auth0 माइग्रेशन में क्या शामिल होता है — उबाऊ हिस्से, झंझट भरे हिस्से, और वह एक सचमुच मुश्किल हिस्सा — ताकि आप खुद इसका आकलन कर सकें।

आपके Auth0 tenant में क्या है

कुछ चीज़ों को कहीं नई जगह जाना ही होता है:

• Applications → OAuth/OIDC clients। Callbacks, logout URLs, allowed origins, grant types, और client secret। यांत्रिक काम है।
• APIs (resource servers) + scopes → audiences और scopes, उन clients से जुड़े हुए जो उनका उपयोग करते हैं (Auth0 इसे "client grants" के रूप में ट्रैक करता है)।
• Roles और उनके assignments → roles + प्रति-उपयोगकर्ता role links।
• Connections → एंटरप्राइज़ (OIDC/SAML), social, और database connections। एंटरप्राइज़ OIDC साफ़-सुथरे ढंग से एक federated provider पर मैप होता है; बाक़ी को आप फिर से कॉन्फ़िगर कर लेते हैं।
• Users → profiles, metadata, और जुड़ी हुई social/enterprise identities।

सिद्धांत रूप में इनमें से कुछ भी मुश्किल नहीं है। घबराहट तीन ख़ास चीज़ों से आती है।

तीन चीज़ें जो लोगों को घबरा देती हैं

1. identities को स्थिर रखना। आपके उपयोगकर्ताओं को उनके sub से (और आपके apps को client_id से) हर जगह संदर्भित किया जाता है — downstream apps के पास रखे refresh tokens, ग्राहक IdPs में SCIM rows, आपके अपने database में संग्रहीत user IDs। अगर कोई माइग्रेशन नई IDs बनाता है, तो यह सब चुपचाप टूट जाता है। इसका समाधान कहने में सरल है और सही करना ज़रूरी है: Auth0 के user_id को sub के रूप में बनाए रखें और client_id को हूबहू रखें। फिर downstream में कुछ भी अंतर नहीं देखता।

2. Passwords — सचमुच मुश्किल वाली चीज़। Auth0 का Management API password hashes कभी नहीं लौटाता। यह Auth0 की जानबूझकर बनाई गई नीति है, आपके टूलिंग की कोई कमी नहीं। आपके पास दो ईमानदार रास्ते हैं:

• Auth0 के support-assisted bulk export का अनुरोध करें, जो आपको एक NDJSON फ़ाइल देता है जिसमें हर उपयोगकर्ता का bcrypt hash होता है। Bcrypt portable है — जो भी bcrypt को verify करता है, वह उन hashes को हूबहू ले सकता है, और आपके उपयोगकर्ताओं को कुछ भी reset नहीं करना पड़ता।
• या hashes को पूरी तरह छोड़ दें और उपयोगकर्ताओं से पहली बार sign-in पर नया password सेट करवाएँ। कुछ भी "खोता" नहीं है — ले जाने के लिए कोई hash था ही नहीं — लेकिन यह आपके उपयोगकर्ताओं के लिए एक दिखने वाला क़दम है।

hashes के लिए कोई self-serve API नहीं है। जो भी आपसे कहे कि कोई one-click Auth0 export उस support फ़ाइल के बिना passwords शामिल करता है, वह बस हवाबाज़ी कर रहा है।

3. 1,000-उपयोगकर्ता की सीमा। Auth0 का user-listing API ज़्यादा से ज़्यादा 1,000 उपयोगकर्ता लौटाता है। किसी बड़े tenant के लिए, bulk export फ़ाइल (वही जो hashes ले जाती है) उपयोगकर्ताओं का असली, पूर्ण स्रोत है — live API नहीं।

इसे एक क्लिक का बनाना

यही वह चीज़ है जो हमने Authagonal में बनाई। आप importer को एक Auth0 machine-to-machine app (केवल read scopes) की ओर इंगित करते हैं, और यह:

• पहले एक read-only preview चलाता है — यह हर application, API, role, connection, और user को गिनता है जिसे वह import करेगा और किसी भी ऐसी चीज़ को चिह्नित करता है जिस पर ध्यान देना ज़रूरी है। जब तक आप commit नहीं करते, तब तक कुछ भी लिखा नहीं जाता।
• applications, API scopes/audiences, roles + assignments, users + metadata, और enterprise OIDC connections को ले आता है — sub और client_id को बनाए रखते हुए ताकि मौजूदा tokens और references resolve होते रहें।
• Auth0 के (read पर plaintext वाले) client secrets को फिर से hash करता है ताकि आपके apps बिना rotation के authenticate होते रहें।
• अगर आप export फ़ाइल देते हैं, तो bcrypt password hashes को हूबहू import करता है — और वह फ़ाइल 1,000-उपयोगकर्ता की सीमा को भी हटा देती है। कोई export नहीं? उपयोगकर्ता पहली बार sign-in पर password सेट कर लेते हैं।

और क्योंकि एंटरप्राइज़ फ़ीचर्स (SAML, SCIM, MFA, audit logs, custom domains) हर प्लान में शामिल हैं, न कि प्रति connection मीटर किए जाते हैं, इसलिए जिस चीज़ ने आपको बाहर की ओर धकेला था, वह दूसरी तरफ़ आपका इंतज़ार नहीं कर रही होगी।

माइग्रेशन की टेस्टिंग पर एक बात

हम importer को एक असली, seeded database के ख़िलाफ़ टेस्ट करते हैं, mocks के ख़िलाफ़ नहीं — और इसने अपनी क़ीमत वसूल की। ASP.NET Identity LockoutEnd को एक datetimeoffset के रूप में संग्रहीत करता है, और इसे GetDateTime() से पढ़ने पर उस type पर exception आता है। एक अकेला locked-out उपयोगकर्ता पूरे import को फ़ेल कर देता। आप इसे केवल असली डेटा के ख़िलाफ़ असली importer चलाकर ही पकड़ते हैं। अगर आप किसी माइग्रेशन टूल का मूल्यांकन कर रहे हैं, तो पूछिए कि इसे कैसे टेस्ट किया गया है — "हम source API को mock करते हैं" वही बात नहीं है जो "हम इसे एक भरे हुए tenant के ख़िलाफ़ चलाते हैं।"

अगर आप बाहर निकलने की सोच रहे हैं

माइग्रेशन उतना डरावना नहीं है जितना आप डरते हैं — इसका preview देखें, अपनी IDs बनाए रखें, अपना password रास्ता तय करें — और एकमात्र असली अड़चन है Auth0 का hash export। अगर आप देखना चाहते हैं कि आपके tenant से क्या आएगा, तो preview read-only है और commit करने से पहले आपको सब कुछ दिखा देता है।

→ Auth0 से माइग्रेट करें