2026/2/17

Auth0機能

ダウンタイムなしでID移行を実現するAuth0の「自動マイグレーション」機能

ID基盤の刷新プロジェクトにおいて、最大の懸念事項は「既存ユーザデータの移行」です。数万〜数百万のユーザ情報を損なうことなく、かつユーザの手を煩わせずに新基盤へ移すことは、サービスの継続性において極めて重要です。

Auth0の「自動マイグレーション（Automatic Migration）」は、ユーザがログインした瞬間にデータを移行することで、従来の「サービス停止」や「パスワード再設定の強制」といった課題をスマートに解決します。

本コラムでは各移行方式を比較し、自動マイグレーションの仕組みとメリット、導入時に懸念されるポイントへの対策について解説します。

従来のデータ移行手法における課題

ID基盤の移行には大きく分けて「一括インポート」と「ユーザセルフ移行」の2つの手法がありますが、それぞれに課題が存在します。

1. ファイルインポート（一括移行）の課題

CSVやJSONファイルを用いて旧DBからデータをエクスポートし、新基盤へインポートする手法です。
この手法については以下のデメリットが存在します。

サービス停止（ダウンタイム）が必須: データの整合性を保つため、エクスポートからインポート完了までの間、サービスを停止するか、更新を凍結する必要があります。
セキュリティリスク: ハッシュ化されたパスワードを含む全データをファイルとして抽出・移動するため、漏洩リスクが高まります。
ハッシュアルゴリズムの互換性: 旧基盤独自のハッシュ化方式が新基盤でサポートされていない場合、インポート自体ができず、全ユーザにパスワード再設定を強いることになります。

2. ユーザセルフ移行（並行運用）の課題

新旧2つの認証基盤を並行稼働させ、ユーザ自身に移行作業を行ってもらう手法です。一見シンプルに見えますが、紐づけの実装とユーザ体験（UX）においては課題があります。

画面フローイメージ

この手法については以下のデメリットが存在します。

アカウント紐付けロジックの実装: 単にログイン画面を2つ用意するだけでは不十分です。「新IDを作成」させた後、「旧IDでログイン」させて本人確認を行い、バックエンドでこの2つのアカウントを安全に紐付ける（Link）ロジックを独自に開発する必要があります。これには高いセキュリティ設計と工数が求められます。
複雑なUX: ユーザに「登録後にさらに旧IDでログインする」という煩雑な手順を強いることになり、離脱の大きな要因となります。

Auth0自動マイグレーションとそのメリット

Auth0の自動マイグレーション機能は、これらの課題を「ログイン時のリアルタイム移行」によって解決します。

以下が自動マイグレーション機能のメリットとなります。

ダウンタイム不要: ユーザがログインする都度、個別にデータが移行されるため、大規模なメンテナンス停止が不要です。
パスワードリセット不要: 旧基盤のパスワードハッシュを検証に利用するため、ユーザは「いつものパスワード」でそのままログインできます。
シームレスなUX: ユーザに見えるのはAuth0のログイン画面ひとつだけです。裏側で移行が行われていることをユーザが意識することはありません。

実装方法：Custom Database Scripts

この機能は、Auth0の「Custom Database」接続を利用し、Node.jsスクリプトを介して旧DBと通信することで実現します。

1. Login スクリプト：移行の実行

ユーザがログイン画面でIDとパスワードを入力した際に発火します。Auth0内部にユーザが存在しない場合のみ実行されます。

画面フローイメージ

処理の流れ

ユーザがログイン画面で情報を入力してから、移行が完了しログインに成功するまでの詳細なフローは以下の通りです。

1.ログインの試行

ユーザはAuth0のログイン画面（Universal Login）でメールアドレスとパスワードを入力し、ログインボタンを押下します。

2.Auth0内部の検索

Auth0はまず、Auth0内部のデータベース（Connection）に該当するメールアドレスを持つユーザが存在するかを確認します。

存在する場合： Auth0が保持しているパスワードハッシュと照合を行い、認証します（Loginスクリプトは実行されません）。
存在しない場合：次のステップ（Loginスクリプト）へ進みます。

3.Login スクリプトの実行

Auth0内にユーザが見つからないため、Auth0は設定されたカスタムデータベース接続の Login スクリプトをトリガーします。このスクリプトは、入力されたメールアドレスとパスワードを引数として受け取ります。

4.旧DBでの認証検証

スクリプトは旧DBに接続し、メールアドレスでユーザを検索します。該当ユーザが見つかった場合、入力された平文パスワードがレガシーDB内の既存パスワード（ハッシュ値など）と一致するか検証します。

5.プロファイルの返却と移行（Import）

認証成功の場合：スクリプトは、旧DBから取得したユーザ情報（ID、名前など）をAuth0に返却します。これを受け取ったAuth0は、即座にAuth0側にユーザレコードを作成し、入力されたパスワードをAuth0側のセキュアな形式でハッシュ化して保存します。これでアカウント情報の移行は完了です。
認証失敗（パスワード違い/ユーザ不在）の場合：スクリプトはエラーを返します。Auth0はユーザに対して「ユーザ名またはパスワードが違います」といった通常のエラーを表示し、移行は行われません。

6.トークンの発行

移行（ステップ5）が成功すると、Auth0はそのまま認証プロセスを続行し、アプリケーションに対してIDトークンやアクセストークンを発行します。

7.ログイン完了

ユーザは裏側で移行処理が行われたことに気づくことなく、通常通りアプリケーションへのログインが完了します。次回以降のログインでは、ステップ2で「Auth0内部に存在する」と判定されるため、レガシーDBへのアクセスは発生しません。

サンプルコード

function login(email, password, callback) {
  // レガシーシステムに対して認証を試行
  // (API経由でパスワードを送る、もしくはDBからハッシュを取得して比較するなど)
  legacyClient.authenticate(email, password, function (err, user) {
    if (err || !user) {
      // 認証失敗
      return callback(new Error('Wrong email or password'));
    }


    // 認証成功時、ユーザ情報を返却（＝Auth0へ移行）
    return callback(null, {
      user_id: user.id,
      email: user.email,
      name: user.name
    });
  });
}

2. Get User スクリプト：パスワードリセットの実現

パスワード検証を行わずにユーザ情報の有無を確認するスクリプトです。「未移行ユーザのパスワードリセット」において重要な役割を果たします。

課題: 未移行ユーザはAuth0に存在しないため、通常は「パスワード忘れ」機能が使えません。
解決策: このスクリプト経由で旧DBを検索し、ユーザが存在すればAuth0は「一時的なユーザ」を作成してリセットメールを送信します。
効果: これにより、旧システムの「パスワードリセット画面」を維持する必要がなくなり、すべての画面をAuth0に統一できます。

画面フローイメージ

処理の流れ

ユーザがパスワードリセットをリクエストしてから、自動的にアカウントが移行され、リセットメールが届くまでの詳細なフローは以下の通りです。

1.パスワードリセットの要求

ユーザはAuth0のログイン画面（Universal Login）にある「パスワードを忘れた場合」リンクをクリックし、自身のメールアドレスを入力してリセットメールの送信を要求します。

2.Auth0内部の検索

Auth0はまず、Auth0内部のデータベース（Connection）に該当するメールアドレスを持つユーザが存在するかを確認します。

存在する場合：通常通り、Auth0ユーザに対してリセットメールを送信します（処理終了）。
存在しない場合：次のステップ（Get Userスクリプト）へ進みます。

3.Get User スクリプトの実行

Auth0内にユーザが見つからないため、Auth0は設定されたカスタムデータベース接続の Get User スクリプトをトリガーします。このスクリプトは、入力されたメールアドレスを引数として受け取ります。

4.旧DBへの問い合わせ

スクリプトは旧DB（既存のDB）に接続し、メールアドレスをキーにしてユーザを検索します。

5.プロファイルの返却と移行（Import）

ユーザが見つかった場合：スクリプトは、旧DBから取得したユーザ情報（ID、メールアドレス、名前など）をJSONオブジェクトとしてAuth0に返却します。これを受け取ったAuth0は、即座にAuth0側にユーザレコードを作成（移行）します。この時点ではパスワードは移行されませんが、ユーザの実体（プロファイル）がAuth0内に作られます。
ユーザが見つからない場合：スクリプトは null (またはコールバックで空) を返します。Auth0はユーザが存在しないと判断し、処理を終了します（セキュリティ上、ユーザの有無を明示しないような挙動となります）。

6.パスワードリセットメールの送信

ステップ5でユーザがAuth0側に作成されたため、Auth0はそのユーザに対して正しくパスワードリセットメールを送信します。

7.パスワードの再設定

ユーザがメール内のリンクをクリックし、新しいパスワードを設定します。これにより、Auth0側のユーザレコードにハッシュ化された新パスワードが保存され、移行および再設定プロセスが完了します。

サンプルコード

function getByEmail(email, callback) {
  // パスワード検証は行わず、ユーザの存在のみを確認
  legacyClient.findUser(email, function (err, user) {
    if (user) {
      // ユーザが存在すればプロファイルを返す
      return callback(null, {
        user_id: user.id,
        email: user.email,
        name: user.name
      });
    } else {
      return callback(null);
    }
  });
}

導入時の考慮事項と解決策

自動マイグレーションは強力な機能ですが、導入にあたってはいくつかの考慮事項があります。しかし、これらは適切な運用設計によって十分にコントロール可能です。

1. 旧DBの運用期間長期化

懸念点: 自動移行は「ログインしたユーザ」のみが対象となるため、長期間ログインしないユーザ（休眠ユーザ）がいる限り、理論上は旧DBを停止できない課題が発生します。
解決策：「期限付きの自動マイグレーション」を採用することが一般的です。例えば「移行期間を1年間」と設定し、その間にログインしたアクティブユーザ（最も価値のある顧客層）は自動移行でスムーズに救済します。期間終了後、残った休眠ユーザのみを「一括インポート」で移行し、旧DBを停止させます。これにより、アクティブユーザの利便性を守りつつ、旧システムの運用コストも計画的にカットできます。

2. 旧システムへの接続と可用性

懸念点: 移行期間中はAuth0から旧DBへの接続が必要となり、旧DBのダウンタイムがログインに影響する可能性があります。
解決策：旧DBへの依存は「未移行ユーザ」に限定されます。ログインするたびにユーザはAuth0側へ移るため、日が経つにつれて旧DBへのアクセス頻度・依存度は急速に減少していきます。また、接続にはAuth0の固定IPアドレス許可などの標準的なセキュリティ設定が利用できるため、安全な通信経路を確立できます。

3. 初回ログイン時の処理時間

懸念点: 初回のみ旧DBへの問い合わせが発生するため、ログインにわずかなレイテンシー（遅延）が発生する。
解決策：この遅延は一般的に数百ミリ秒〜数秒程度であり、ユーザが一度ログインすれば二度と発生しません。「パスワード再設定メールを受け取り、リンクを開き、新しいパスワードを考える」という手間に比べれば、ユーザにとっての負担は無いに等しいと言えます。

おわりに

Auth0の自動マイグレーションは、システム刷新時の最大の障壁である「ユーザ体験の棄損」を防ぐための最良の手段です。

確かに旧DBとの一時的な並行運用は必要ですが、「アクティブユーザにパスワードリセットを強要しない」というメリットは、ビジネスの継続性においてそれを補って余りある価値があります。企業のポリシーに合わせて「完全自動移行」か、期間を区切った「ハイブリッド移行」かを選択できる柔軟性もAuth0が選ばれる理由の一つです。

弊社では、これまで数多くの統合IDソリューション導入・移行プロジェクトを支援してまいりました。
お客様の既存システムの構成やセキュリティ要件に合わせて、「自動マイグレーション」と「一括インポート」のメリット・デメリットを整理し、最適な移行プランをご提案することが可能です。

スムーズなID基盤移行をご検討の際は、ぜひ一度お問い合わせください。