Una linea guida generale per migrare il tuo database utenti esistente su Logto

Logto non ha ancora una serie di strumenti per la migrazione dei dati, ma abbiamo aperto le capacità di base di Management API. Ciò non ostacolerà gli utenti nel completare la migrazione dei database utenti esistenti scrivendo script.

In vista di alcune delle esigenze ricevute dagli utenti della comunità, e il fatto che attualmente non abbiamo una documentazione che spiega i passaggi specifici della migrazione del database utente, facciamo un'introduzione appropriata in questo articolo per aiutare gli utenti a trovare idee specifiche e risparmiare tempo nella lettura del codice e della documentazione di Logto.

Passo 1: Comprendere la struttura base dei dati utente di Logto e il caso d'uso#

Logto utilizza [database PostgreSQL] (https://www.postgresql.org/about/) sotto il cofano. Oltre ai suoi vari vantaggi di prestazioni, un motivo importante è che supporta il tipo di dati JSON / JSONB personalizzato e consente di costruire indici sui valori interni dei dati di tipo JSON, bilanciando sia le prestazioni del database che l'estensibilità.

Per la struttura dei dati utente di Logto, fare riferimento a [riferimento utente] (https://docs.logto.io/docs/references/users/) per capire tutti i dettagli. Qui ci concentriamo su descrivere alcuni aspetti in cui Logto potrebbe essere diverso da altri servizi di identità.

[id] (https://docs.logto.io/docs/references/users/#id)#

Questo è un identificatore unico interno generato casualmente per gli utenti di Logto. Gli utenti non sono a conoscenza di id quando utilizzano servizi basati su Logto.

Gli ingegneri familiari con i database non dovrebbero trovare ciò strano. Anche i sistemi di identità più rudimentali avranno un id per identificare univocamente gli utenti, sebbene le loro forme spesso differiscano. Alcuni servizi di identità possono utilizzare il nome utente per identificare univocamente gli utenti.

[nome utente] (https://docs.logto.io/docs/references/users/#username), [email primaria] (https://docs.logto.io/docs/references/users/#primary_email), [telefono primario] (https://docs.logto.io/docs/references/users/#primary_phone)#

Qui, il nome utente, l'email primaria, il telefono principale sono dove Logto differisce notevolmente da altri sistemi di identità - possono tutti fungere da identificatori unici percepibili dall'utente finale.

In molti altri sistemi di identità, il nome utente viene utilizzato per l'identificazione (i nomi utente non possono essere duplicati tra gli account), il che è facile da capire.

Ma in Logto, l'email primaria / telefono viene anche utilizzata per distinguere gli utenti. Cioè, se un utente A ha già l'email primaria [email protected], quindi altri utenti B non possono aggiungere questo indirizzo email come loro email primaria. Il telefono primario funziona in modo simile.

Alcuni altri sistemi di identità consentono la registrazione di account multipli con nomi utente diversi ma legando la stessa email / telefono, che non è consentito in Logto (le email / telefoni possono essere aggiunti ai customData di Logto). Questo perché l'email / telefono primario in Logto può essere utilizzato per l'accesso senza password.

[identità] (https://docs.logto.io/docs/references/users/social-identities/)#

Logto definisce questo campo identities come tipo JSON, la sua definizione di tipo:

Negli ultimi anni, per facilitare l'acquisizione di nuovi utenti, i sistemi di identità consentono agli utenti di accedere rapidamente attraverso alcuni account social esistenti con un grande numero di utenti, come google / facebook, ecc.

Nell'esempio di seguito, il campo identities memorizza le informazioni di accesso social:

Dove facebook e github sono i nomi dei fornitori social, userId è l'id dell'account social dell'utente utilizzato per l'accesso. I details includono anche alcune altre informazioni che l'utente ha autorizzato il fornitore social a visualizzare, che verranno aggiunte al profilo utente di Logto in momenti specifici.

Se il database precedente contiene il nome (ad es. facebook, google) e l'id del fornitore social utilizzato dall'utente (vedi userId nell'esempio precedente), allora l'utente Logto può accedere direttamente con lo stesso account social.

[customData] (https://docs.logto.io/docs/references/users/custom-data/)#

Questo campo può memorizzare qualsiasi informazione correlata all'utente, come le email / telefoni menzionati sopra che non possono essere utilizzati per l'accesso senza password (potrebbero essere utilizzati per ricevere notifiche o per altre funzioni commerciali correlate), ecc.

Altri campi sono relativamente facili da capire (ad eccezione di passwordEncrypted e passwordEncryptionMethod che verranno spiegati successivamente), leggete da soli la documentazione.

Passo 2: Scrittura di script di migrazione del database#

Per la migrazione del database di larga scala, la scrittura di script di migrazione è l'approccio più comune. Forniremo un semplice esempio per aiutare a capire come scrivere script di migrazione per soddisfare diverse esigenze.

Va notato che quando si scrivono script di migrazione, saltiamo il processo di recupero dei dati originali, perché ci sono molti modi per ottenere i dati, come l'esportazione dal database ai file e poi la lettura dei file, o il recupero attraverso le API. Questi non sono il focus dello script di migrazione, quindi non li discuteremo in dettaglio qui.

Quando vedi tenant_id nello script di migrazione, potresti trovarlo strano. Logto si basa su un'architettura multi-tenant. Per gli utenti di Logto open source (Logto OSS), è possibile impostare il tenant_id dell'utente su default.

Per gli utenti auto-ospitati di Logto OSS, la connessione al database è facile da ottenere. Tuttavia, per gli utenti di Logto cloud, per motivi di sicurezza, attualmente non possiamo fornire agli utenti le autorizzazioni di connessione al database. Gli utenti devono fare riferimento alla [API Docs] (https://docs.logto.io/api/#tag/Users) e utilizzare le API correlate agli utenti per migrare gli utenti. Comprendiamo che questo metodo non è adatto per la migrazione di dati utente su larga scala, ma può comunque gestire la migrazione di un numero limitato di utenti in questa fase.

Passo 3: Sfida alla migrazione della password hashata e possibile soluzione#

Nel nostro precedente [blog] (https://blog.logto.io/cracking-password/), abbiamo parlato di alcune misure per prevenire gli attacchi alle password. Una cosa che i fornitori di infrastruttura di identità possono fare è non memorizzare le password in chiaro ma salvare le password hashate.

Un altro [post del blog] (https://blog.logto.io/password-hashing/) ha spiegato gli hash delle password, dove abbiamo affermato che i valori hash sono irreversibili.

Il secondo post del blog ha anche paragonato l'evoluzione di alcuni algoritmi di hashing. Logto stesso utilizza l'algoritmo Argon2i menzionato nell'articolo e non supporta altri algoritmi di hash per ora. Ciò significa che gli hash delle password dei vecchi database utente che utilizzano altri algoritmi di hashing non possono essere migrati direttamente sul database di Logto.

Anche se Logto supporta altri algoritmi di hash comunemente utilizzati oltre ad Argon2i, sarebbe comunque difficile migrare direttamente i vecchi dati a causa della flessibilità del sale durante l'applicazione degli algoritmi di hashing.

Oltre a supportare altri algoritmi di hashing in futuro, Logto è anche probabile che fornisca metodi di calcolo del sale personalizzati per adattarsi a varie situazioni.

Prima di ciò, puoi utilizzare la [configurazione dell'esperienza di accesso di Logto] (https://docs.logto.io/docs/recipes/customize-sie/) per consentire agli utenti di accedere in altri modi (come email + codice di verifica) e compilare una nuova password (che utilizzerà l'algoritmo di hashing Argon2i) prima di entrare nell'app. Poi la nuova password può essere utilizzata per accedere successivamente.

Va notato che se i dati utenti originali supportano solo l'accesso con una password, la soluzione alternativa menzionata sopra non funzionerà per questo scenario. Questo perché la soluzione alternativa menzionata in precedenza risolve effettivamente il problema dell'incompatibilità del hash della password utilizzando metodi di accesso alternativi e sfruttando il meccanismo di "completamento delle informazioni richieste" nel flusso end-user di Logto.

Quindi se nei dati utenti originali è supportato solo l'accesso con password, la soluzione alternativa non può risolvere questa situazione, poiché non ci sono opzioni di accesso alternative disponibili.

La soluzione alternativa menzionata qui non risolve davvero il problema della migrazione della password hashata, ma fornisce una soluzione alternativa dal punto di vista del prodotto Logto per evitare di ostacolare gli utenti nell'accesso al tuo prodotto.

Passo 4: Passaggio graduale a Logto e monitoraggio dello stato#

Dopo aver completato i passaggi precedenti, gli utenti finali possono già effettuare l'accesso e utilizzare il tuo servizio tramite Logto.

Poiché il servizio di solito non viene interrotto durante la migrazione, è possibile che i dati utente sincronizzati su Logto non siano aggiornati. Quando vengono rilevati tali casi poco comuni, è necessario eseguire la sincronizzazione dal vecchio database a Logto.

Dopo un periodo di tempo più lungo (o possono essere applicate altre metriche definite) senza l'occorrenza di dati incoerenti, il vecchio database può essere completamente abbandonato.

Conclusione#

Nel post, abbiamo introdotto i passaggi attraverso cui passerebbe una migrazione del database ideale.

Se incontri problemi non menzionati sopra, non esitare a unirti alla nostra community o contattarci per aiuto. I problemi che incontri potrebbero essere riscontrati anche da altri, e diventeranno problemi che dobbiamo considerare quando progettiamo gli strumenti di migrazione in futuro.