En allmän riktlinje för att migrera din befintliga användardatabas till Logto

Logto har ännu inte en serie verktyg för datamigrering, men vi har öppnat upp grundläggande kapaciteter för Management API. Detta kommer inte att hindra användare från att genomföra migrering av befintliga användardatabaser genom att skriva skript.

Med hänsyn till några av de behov som mottagits från community-användare, och det faktum att vi för närvarande inte har någon dokumentation som förklarar de specifika stegen för användardatabas-migrering, ger vi en ordentlig introduktion i denna artikel för att hjälpa användare att hitta specifika idéer och spara tid på att läsa Logto-kod och dokumentation.

Steg 1: Förstå Logtos grundläggande användardatastruktur och användningsfall#

Logto använder PostgreSQL-databas under huven. Förutom dess olika prestandafördelar är en viktig anledning att den stöder anpassad JSON/JSONB-datatype och tillåter indexering att byggas på interna värden av JSON-typad data, vilket balanserar både databasprestanda och utbyggbarhet.

För Logtos användardatastruktur, vänligen hänvisa till användarreferens för att förstå alla detaljer. Här fokuserar vi på att beskriva några aspekter där Logto kan skilja sig från andra identitetstjänster.

id#

Detta är en slumpmässigt genererad intern unik identifierare för Logtos användare. Användare är omedvetna om id när de använder tjänster baserade på Logto.

Ingenjörer som är bekanta med databaser bör inte finna detta konstigt. Även de mest grundläggande identitetssystemen kommer att ha en id för att unikt identifiera användare, även om deras former ofta skiljer sig åt. Vissa identitetstjänster kan använda användarnamn för att unikt identifiera användare.

username, primaryEmail, primaryPhone#

Här skiljer sig användarnamn, primär e-post, primär telefon mycket från andra identitetssystem - de kan alla fungera som slutändaranvändarens uppfattbara unika identifierare.

I många andra identitetssystem används användarnamn för identifiering (användarnamn kan inte dupliceras mellan konton), vilket är lätt att förstå.

Men i Logto används primär e-post/telefon också för att skilja användare. Det vill säga, om en användare A redan har den primära e-posten [email protected], så kan inte andra användare B lägga till denna e-postadress som deras primära e-post. Primär telefon fungerar liknande.

Vissa andra identitetssystem tillåter registrering av flera konton med olika användarnamn men bindning av samma e-post/telefon, vilket inte är tillåtet i Logto (e-post/telefon kan läggas till Logtos customData). Detta eftersom primär e-post/telefon i Logto kan användas för lösenordslös inloggning.

identities#

Logto definierar detta identities-fält som JSON-typ, dess typdefinition:

Under de senaste åren, för att underlätta förvärv av nya användare, tillåter identitetssystem användare att snabbt logga in genom några befintliga sociala konton med en stor användarbas, såsom google / facebook, etc.

I exemplet nedan lagrar identities-fältet social information för inloggning:

Där facebook och github är namnen på de sociala leverantörerna, userId är id för användarens sociala konto som används för inloggning. details inkluderar också annan information som användaren har godkänt den sociala leverantören att visa, vilket kommer att läggas till användarens Logto-användarprofil vid specifika tider.

Om den tidigare databasen innehåller namnet (t.ex. facebook, google) och id för den sociala leverantören som används av användaren (se userId i tidigare exempel), kan Logto-användaren logga in direkt med samma sociala konto.

customData#

Detta fält kan lagra all användarrelaterad information, såsom ovan nämnda e-post/telefonnummer som inte kan användas för lösenordslös inloggning (kan användas för att ta emot aviseringar eller för andra affärsrelaterade funktioner), etc.

Andra fält är relativt lätta att förstå (förutom passwordEncrypted och passwordEncryptionMethod som kommer att förklaras senare), vänligen läs dokumentationen själv.

Steg 2: Skriva databas-migreringsskript#

För storskalig databas-migrering är det vanligaste tillvägagångssättet att skriva migreringsskript. Vi kommer att tillhandahålla ett enkelt exempel för att hjälpa till att förstå hur man skriver migreringsskript för att möta olika behov.

Det bör noteras att när man skriver migreringsskript, hoppar vi över processen för att hämta den ursprungliga datan, eftersom det finns många sätt att få data, såsom att exportera från databasen till filer och sedan läsa filerna, eller hämta genom API:er. Dessa är inte fokus för migreringsskriptet, så vi kommer inte att diskutera dem i detalj här.

När du ser tenant_id i migreringsskriptet, kan du tycka att det är konstigt. Logto är baserat på en flerhyrarkitektur. För open source Logto (Logto OSS) användare, kan du bara ställa in tenant_id för användaren till default.

För självhostade Logto OSS-användare är databasanslutningen lätt att få tag på. Men för Logto molnanvändare, av säkerhetsskäl, kan vi för närvarande inte tillhandahålla databasanslutningsbehörigheter till användare. Användare behöver hänvisa till API-dokumentation och använda de användarrelaterade API:erna för att migrera användare. Vi förstår att den här metoden inte är lämplig för storskalig migrering av användardata, men kan fortfarande hantera migrering av ett begränsat antal användare i detta skede.

Steg 3: Utmaning och potentiell lösning för migrering av hashade lösenord#

I vår tidigare blogg, pratade vi om några åtgärder för att förhindra lösenordsattacker. En sak identitetsinfrastrukturleverantörer kan göra är att inte lagra lösenord i klartext utan spara hashade lösenord.

Ett annat blogginlägg förklarade lösenordshashar, där vi konstaterade att hashvärden är irreversibla.

Det andra blogginlägget jämförde också utvecklingen av vissa hashningsalgoritmer. Logto använder själv Argon2i-algoritmen som nämns i artikeln och stöder för närvarande inte andra hashalgoritmer. Detta innebär att lösenordshashar från gamla användardatabaser som använder andra hashningsalgoritmer inte kan migreras direkt till Logtos databas.

Även om Logto stöder andra vanliga hashningsalgoritmer utöver Argon2i, skulle det fortfarande vara svårt att direkt migrera gammal data på grund av flexibiliteten hos saltet när man tillämpar hashningsalgoritmer.

Förutom att stödja andra hashalgoritmer i framtiden, är det också troligt att Logto kommer att tillhandahålla anpassade saltberäkningsmetoder för att anpassa sig till olika situationer.

Innan dess kan du använda Logtos inloggningsupplevelsekonfiguration för att tillåta användare att logga in på andra sätt (såsom e-post + verifieringskod) och fylla i ett nytt lösenord (som kommer att använda Argon2i-hashningsalgoritmen) innan du går in i appen. Sedan kan det nya lösenordet användas för att logga in senare.

Det bör noteras att om den ursprungliga användardatan endast stödjer inloggning med lösenord, kommer den nämnda lösningen ovan inte att fungera för detta scenario. Detta beror på att den tidigare nämnda lösningen faktiskt löser problemet med lösenordshashkompatibilitet genom att använda alternativa inloggningsmetoder och utnyttja "krävt informationskompletterings"-mekanismen i Logtos slutanvändarflöde.

Så om endast lösenordsinloggning stöds i den ursprungliga användardatan, kan lösningen inte lösa denna situation, eftersom inga alternativa inloggningsalternativ finns tillgängliga.

Lösningen som nämns här löser inte egentligen problemet med migrering av hashade lösenord, men ger en alternativ lösning från Logto-produktperspektivet för att undvika att hindra användare från att logga in på din produkt.

Steg 4: Gradvis övergång till Logto och statusövervakning#

Efter att ha slutfört ovanstående steg, kan slutanvändare redan logga in och använda din tjänst genom Logto.

Eftersom tjänsten vanligtvis inte avbryts under migreringen, är det möjligt att användardatan som synkroniserats till Logto inte är uppdaterad. När sådana ovanliga fall upptäcks, behöver synkronisering från den gamla databasen till Logto utföras.

Efter en längre tidsperiod (eller andra definierade mått kan tillämpas) utan förekomst av inkonsekvent data, kan den gamla databasen helt överges.

Slutsats#

I inlägget introducerade vi de steg en ideal databas-migrering skulle genomgå.

Om du stöter på problem som inte nämns ovan, tveka inte att gå med i vår community eller kontakta oss för hjälp. Problemen du möter kan också stötas på av andra, och kommer att bli frågor vi behöver överväga när vi designar migreringsverktyg i framtiden.