日本語
既存のユーザーデータベースを Logto に移行する総合的なガイドライン
この記事では、Logto がまだデータ移行サービスを提供していない状況で、既存のツールを利用して前のユーザーデータを Logto に移行する方法を紹介します。
Darcy Ye
Developer
Developer
この記事では、Logto がまだデータ移行サービスを提供していない状況で、既存のツールを利用して前のユーザーデータを Logto に移行する方法を紹介します。
Logto はまだデータ移行の一連のツールを用意していないが、基本的な管理 API の機能を開放しています。これにより、ユーザーがスクリプトを書くことで既存のユーザーデータベースの移行を完了することを妨げません。
コミュニティユーザーから受け取ったいくつかのニーズ、および現在ユーザーデータベースの移行の具体的な手順を説明する文書がないという事実を考慮に入れ、この記事で詳しく紹介し、ユーザーが特定のアイデアを見つけ出し、Logto のコードとドキュメンテーションを読む時間を節約するための支援を行います。
Logto は、内部では PostgreSQL データベース を使用しています。パフォーマンスの優れた特性の他、カスタム JSON/JSONB データ型をサポートし、JSON 型データの内部値にインデックスを作成してデータベースのパフォーマンスと拡張性を両立させるという重要な理由があります。
Logto のユーザーデータ構造については、ユーザーリファレンスを参照して全ての詳細を理解してください。ここでは、Logto が他のアイデンティティーサービスと異なる可能性があるいくつかの側面について説明します。
これは、Logto のユーザーに対して内部でランダムに生成される一意の識別子です。ユーザーは、Logto ベースのサービスを使用する際に id を認識しません。
データベースに詳しいエンジニアであれば、これに違和感を感じることはありません。最も基本的なアイデンティティーシステムでも、ユーザーを一意に識別する id を持っていますが、その形式はしばしば異なります。一部のアイデンティティーサービスでは、ユーザーを一意に識別するためにユーザー名を使用することがあります。
ここでは、ユーザーネーム、 メインのEメール、 メインの電話番号が Logto と他のアイデンティティーシステムと大幅に異なり、エンドユーザーが認識できる一意の識別子として機能することがあります。
多くの他のアイデンティティーシステムでは、ユーザーネームが識別用に使われています（ユーザーネームはアカウント間で重複することはできません）。これは理解しやすいです。
しかし Logto では、メインの E メール/電話もユーザーを区別するために使用されます。つまり、ユーザー A が既に [email protected] のメインメールを持っていた場合、他のユーザー B はこの E メールアドレスを自分のメイン E メールとして追加することはできません。メインの電話は同様の方法で機能します。
他のアイデンティティーシステムでは、異なるユーザーネームで複数のアカウントを登録し、同じEメール/電話 をバインドすることが許可されていることがありますが、 Logto では許可されていません（ E メール/電話は Logto の customData に追加できます）。「メインのメールEメール/電話」は Logto でパスワードレスのサインインに使用することができます。
Logto は、この identities フィールドを JSON 型として定義しています。その型の定義は次のとおりです。
近年、新規ユーザーの獲得を容易にするために、アイデンティティーシステムは、 google / facebook など、既存のソーシャルアカウントを通じてユーザーが素早くログインできるようにしています。
以下の例では、 identities フィールドはソーシャルログイン情報を格納します。
ここで、 facebook と github はソーシャルプロバイダーの名前で、 userId はログインに使われるユーザーのソーシャルアカウントの id です。 details は、ユーザーがソーシャルプロバイダーに表示を許可した他の情報も含み、具体的なタイミングでユーザーの Logto ユーザープロファイルに追加されます。
以前のデータベースにユーザーが使用したソーシャルプロバイダーの名前（たとえば、facebook , google ）と id が含まれている場合、Logto のユーザーは同じソーシャルアカウントで直接ログインすることができます。
このフィールドには、パスワードレスサインインに利用できない上記のメール/電話など、ユーザーに関連するあらゆる情報を格納することができます（通知を受け取ったり、他のビジネス関連の機能に使用したりするためかもしれません）。
他のフィールドは比較的理解しやすい（passwordEncrypted と passwordEncryptionMethod を除く、これらについては後で説明します）。ドキュメンテーションを自分で読んでください。
大規模なデータベース移行には、移行スクリプトの作成が一般的な方法です。異なるニーズを満たすための移行スクリプトの作成方法を理解するための簡単な例を提供します。
移行スクリプトを作成する際に注意すべき点は、元のデータを取得するプロセスをスキップしていることです。データを取得する方法はたくさんあります。たとえば、データベースからファイルにエクスポートしてからファイルを読み込むことや、API を通じて取得することなどです。これらは移行スクリプトの焦点ではないため、ここでは詳しく説明しません。
移行スクリプトで tenant_id を見ると、少し奇妙に感じるかもしれません。 Logto はマルチテナントアーキテクチャに基づいています。オープンソース Logto (Logto OSS) のユーザーには、ユーザーの tenant_id を default に設定するだけです。
自分でホストした Logto OSS ユーザーにとって、データベース接続は簡単に取得できます。しかし、 Logto クラウドユーザーにとっては、セキュリティー上の理由から、現在ユーザーに対してデータベース接続権を提供することはできません。ユーザーは、 API Docs を参照し、ユーザー関連 API を使用してユーザーを移行する必要があります。我々は、この方法が大量のユーザーデータの移行には適していないことを理解していますが、現段階で限られた数のユーザーを移行することはまだ可能です。
我々の以前の ブログ で、パスワード攻撃を防ぐためのいくつかの対策について話しました。アイデンティティーインフラプロバイダーができることの1つは、パスワードをプレーンテキストで保管するのではなく、ハッシュ化されたパスワードを保存することです。
別の ブログ投稿 では、パスワードのハッシュについて説明し、ハッシュ値は逆転できないことを明記しました。
2つ目のブログ投稿では、いくつかのハッシングアルゴリズムの進化を比較しました。Logto 自体は、記事で言及された Argon2i アルゴリズムを使用し、現時点では他のハッシュアルゴリズムはサポートしていません。これは、他のハッシングアルゴリズムを使用した古いユーザーデータベースのパスワードハッシュが、Logto のデータベースに直接移行できないことを意味します。
もし Logto が Argon2i に加えて他の一般的に使用されるハッシュアルゴリズムもサポートするとしても、ハッシングアルゴリズムを適用する際の塩（ salt ）の柔軟性のために、古いデータを直接移行するのは依然として難しいでしょう。
Logto は、将来的に他のハッシングアルゴリズムをサポートするだけでなく、様々な状況に対応するためのカスタム塩計算方法を提供する可能性もあります。
その前に、Logto の サインイン体験設定 を使用して、ユーザーが他の方法（メール + 認証コードなど）でサインインし、アプリに入る前に新しいパスワード（これは Argon2i ハッシングアルゴリズムを使用します）を入力することができます。その後、新しいパスワードを使用してサインインすることができます。
ここで注意すべき点は、元のユーザーデータがパスワードでのみログインをサポートしている場合、上記で述べたワークアラウンドはこのシナリオでは機能しないということです。これは、前述のワークアラウンドが実際には代替的なサインイン方法を使用して Logto のエンドユーザーフローの「必要な情報の完成」メカニズムを活用し、パスワードハッシュの非互換性問題を解決しているからです。
したがって、元のユーザーデータがパスワードログインのみをサポートしている場合、このワークアラウンドではこの状況を解決できず、代替のログインオプションが利用できないからです。
ここで述べているワークアラウンドは、実際にはハッシュ化されたパスワードの移行問題を解決していませんが、Logto プロダクトからの代替的な解決策を提供し、ユーザーが製品にログインするのを妨げないようにします。
上記のステップを完了すると、エンドユーザーは既に Logto を通じてあなたのサービスにログインして使用することができます。
通常、移行中にサービスが切断されることはないため、 Logto に同期されたユーザーデータが最新ではない可能性があります。そのような一般的でないケースが検出された場合、旧データベースから Logto への同期が必要となります。
長期間（または他の定義された指標が適用されるかもしれません）にわたって一貫性のないデータが発生しない場合、旧データベースは完全に放棄することができます。
この投稿では、理想的なデータベース移行が経験するステップを紹介しました。
もし上記で触れられていない問題に遭遇した場合は、遠慮なく私たちのコミュニティに参加したり、私たちに連絡したりしてください。あなたが遭遇する問題は他の人も遭遇する可能性があり、それは私たちが将来の移行ツールを設計する際に考慮すべき問題となります。