Dit artikel introduceert hoe je bestaande tools kunt gebruiken om eerdere gebruikersdata naar Logto te migreren, in situaties waarin Logto nog geen datamigratiediensten heeft geboden.
Logto heeft nog geen reeks tools voor datamigratie, maar we hebben de basisfunctionaliteiten van de Management API opengesteld. Dit zal gebruikers niet verhinderen om de migratie van bestaande gebruikersdatabases te voltooien door scripts te schrijven.
Gezien enkele behoeften die zijn ontvangen van communitygebruikers, en het feit dat we momenteel geen documentatie hebben die de specifieke stappen van gebruikersdatabasemigratie uitlegt, geven we in dit artikel een goede introductie om gebruikers te helpen specifieke ideeën te vinden en tijd te besparen bij het lezen van Logto-code en -documentatie.
Logto gebruikt PostgreSQL database onder de motorkap. Naast zijn verschillende prestatievoordelen is een belangrijke reden dat het aangepaste JSON/JSONB datatypen ondersteunt en toestaat indexering te bouwen op interne waarden van JSON-getypeerde data, wat zowel databaseprestaties als uitbreidbaarheid in balans houdt.
Voor Logto's gebruikersdatastructuur, raadpleeg de user reference om alle details te begrijpen. Hier richten we ons op het beschrijven van enkele aspecten waar Logto mogelijk verschilt van andere identiteitsdiensten.
Dit is een willekeurig gegenereerde interne unieke identificator voor gebruikers van Logto. Gebruikers zijn zich niet bewust van id wanneer ze Logto-gebaseerde services gebruiken.
Ingenieurs die bekend zijn met databases zouden dit niet vreemd moeten vinden. Zelfs de meest rudimentaire identiteitsystemen zullen een id hebben om gebruikers uniek te identificeren, hoewel hun vormen vaak verschillen. Sommige identiteitsdiensten kunnen een gebruikersnaam gebruiken om gebruikers uniek te identificeren.
Hier is waar Logto aanzienlijk verschilt van andere identiteitsystemen - ze kunnen allemaal dienen als voor de gebruiker waarneembare unieke identificatoren.
In veel andere identiteitsystemen wordt de gebruikersnaam gebruikt voor identificatie (gebruikersnamen kunnen niet worden gedupliceerd tussen accounts), wat gemakkelijk te begrijpen is.
Maar in Logto worden primaire e-mail/telefoon ook gebruikt om gebruikers te onderscheiden. Dat wil zeggen, als een gebruiker A al de primaire e-mail [email protected] heeft, dan kunnen andere gebruikers B dit e-mailadres niet als hun primaire e-mail toevoegen. Primair telefoon werkt op vergelijkbare wijze.
Sommige andere identiteitsystemen staan toe meerdere accounts te registreren met verschillende gebruikersnamen maar dezelfde e-mail/telefoon te koppelen, wat niet is toegestaan in Logto (e-mails/telefoons kunnen worden toegevoegd aan Logto's customData). Dit komt doordat primaire e-mail/telefoon in Logto kan worden gebruikt voor wachtwoordloze inlog.
Logto definieert dit identities veld als JSON-type, de typedefinitie:
In de afgelopen jaren, om het verkrijgen van nieuwe gebruikers te vergemakkelijken, staan identiteitsystemen gebruikers toe om snel in te loggen via enkele bestaande sociale accounts met een grote gebruikersbasis, zoals google / facebook, etc.
In het onderstaande voorbeeld slaat het identities veld sociale logininformatie op:
Waar facebook en github de namen van de sociale aanbieders zijn, is userId de id van het sociale account dat de gebruiker gebruikt voor inloggen. De details bevatten ook andere informatie die de gebruiker heeft geautoriseerd, de sociale aanbieder te tonen, welke op specifieke momenten aan het gebruikersprofiel van Logto wordt toegevoegd.
Als het eerdere database de naam (bijv. facebook , google) en id van de sociale aanbieder bevat die door de gebruiker wordt gebruikt (zie userId in vorig voorbeeld), dan kan de Logto-gebruiker direct inloggen met hetzelfde sociale account.
Dit veld kan alle gebruikersgerelateerde informatie opslaan, zoals hierboven genoemde e-mails/telefoons die niet kunnen worden gebruikt voor wachtwoordloze login (kan worden gebruikt voor het ontvangen van meldingen of voor andere bedrijfsgerelateerde functies), enz.
Andere velden zijn relatief eenvoudig te begrijpen (behalve passwordEncrypted en passwordEncryptionMethod die later zullen worden uitgelegd), lees de documentatie zelf.
Voor grootschalige databasemigratie is het schrijven van migratiescripts de meest gebruikelijke aanpak. We zullen een eenvoudig voorbeeld geven om te helpen begrijpen hoe migratiescripts te schrijven om aan verschillende behoeften te voldoen.
Het dient opgemerkt te worden dat bij het schrijven van migratiescripts, we het proces van het ophalen van de oorspronkelijke gegevens overslaan, omdat er veel manieren zijn om gegevens te verkrijgen, zoals exporteren uit de database naar bestanden en dan de bestanden lezen, of ophalen via API's. Deze zijn niet de focus van het migratiescript, dus we zullen ze hier niet in detail bespreken.
Wanneer je tenant_id in het migratiescript ziet, vind je het misschien vreemd. Logto is gebaseerd op een multi-tenant architectuur. Voor open source Logto (Logto OSS) gebruikers, kan je gewoon de tenant_id van de gebruiker instellen op default.
Voor zelf-gehoste Logto OSS gebruikers is de databaseverbinding gemakkelijk te verkrijgen. Echter, voor Logto cloud gebruikers, vanwege veiligheidsredenen, kunnen we momenteel geen databaseverbindingsrechten aan gebruikers geven. Gebruikers moeten verwijzen naar de API Docs en de Gebruiker-gerelateerde API's gebruiken om gebruikers te migreren. We begrijpen dat deze methode niet geschikt is voor grootschalige gebruikersdatamigratie, maar kan nog steeds gebruikt worden om een beperkt aantal gebruikers in dit stadium te migreren.
In onze eerdere blog bespraken we enkele maatregelen om wachtwoordaanvallen te voorkomen. Eén ding dat identiteitsinfrastructuurproviders kunnen doen is geen wachtwoorden in platte tekst opslaan maar gehashte wachtwoorden bewaren.
Een andere blogpost legde wachtwoordhashes uit, waar we verklaarden dat hashwaarden onomkeerbaar zijn.
De tweede blogpost vergeleek ook de evolutie van enkele hashalgoritmen. Logto zelf gebruikt het Argon2i-algoritme dat in het artikel wordt genoemd en ondersteunt momenteel geen andere hashalgoritmen. Dit betekent dat wachtwoordhashes van oude gebruikersdatabases die andere hashalgoritmen gebruiken niet direct kunnen worden gemigreerd naar de database van Logto.
Zelfs als Logto naast Argon2i andere veelgebruikte hashalgoritmen zou ondersteunen, zou het nog steeds moeilijk zijn om oude data direct te migreren vanwege de flexibiliteit van zout bij het toepassen van hashalgoritmen.
Naast het ondersteunen van andere hashalgoritmen in de toekomst, is het waarschijnlijk dat Logto ook aangepaste zoutberekeningsmethoden zal bieden om zich aan te passen aan verschillende situaties.
Tot die tijd kun je Logto's aanmeldervaring configuratie gebruiken om gebruikers toe te staan in te loggen via andere manieren (zoals e-mail + verificatiecode) en een nieuw wachtwoord in te vullen (dat het Argon2i hashalgoritme gebruikt) voordat ze de app betreden. Dan kan het nieuwe wachtwoord later worden gebruikt om in te loggen.
Het dient te worden opgemerkt dat als de oorspronkelijke gebruikersdata alleen het inloggen met een wachtwoord ondersteunt, de hierboven genoemde oplossing niet werkt voor dit scenario. Dit komt omdat de eerder genoemde oplossing eigenlijk het wachtwoordhash incompatibiliteitsprobleem oplost door alternatieve inlogmethoden te gebruiken en gebruik te maken van het mechanisme voor het "voltooien van verplichte informatie" in Logto's eindgebruikersstroom.
Dus als alleen wachtwoordlogin wordt ondersteund in de oorspronkelijke gebruikersdata, kan de oplossing dit scenario niet oplossen, aangezien er geen alternatieve inlogopties beschikbaar zijn.
De oplossing die hier wordt genoemd lost het probleem van gehashte wachtwoordmigratie niet echt op, maar biedt een alternatieve oplossing vanuit het productperspectief van Logto om te voorkomen dat gebruikers worden verhinderd in te loggen op je product.
Na voltooiing van de bovenstaande stappen kunnen eindgebruikers al inloggen en je service gebruiken via Logto.
Aangezien de service meestal niet wordt afgesloten tijdens de migratie, is het mogelijk dat de gebruikersdata die naar Logto is gesynchroniseerd niet up-to-date is. Wanneer dergelijke ongebruikelijke gevallen worden gedetecteerd, moet synchronisatie van de oude database naar Logto worden uitgevoerd.
Na een langere periode (of andere gedefinieerde maatstaven kunnen worden toegepast) zonder het optreden van inconsistente data, kan de oude database volledig worden verlaten.
In de post hebben we de stappen geïntroduceerd die een ideale databasemigratie zou doorlopen.
Als je problemen tegenkomt die niet hierboven zijn genoemd, aarzel dan niet om je bij onze community aan te sluiten of contact met ons op te nemen voor hulp. De problemen die je tegenkomt, kunnen ook door anderen worden ervaren en zullen kwesties worden die we moeten overwegen bij het ontwerpen van migratietools in de toekomst.