カスタムデータベース接続の構造に関するベストプラクティス
カスタムデータベース接続は通常、独自のレガシーIDストアにアクセスして認証（レガシー認証と呼ばれることがあります）や自動移行によるユーザーのインポート（トリクルダウン移行またはレイジー移行と呼ばれます）を行うために使用されます。カスタムデータベース接続は、Auth0のマルチテナントアーキテクチャを使用するシナリオで、Auth0テナントへのプロキシアクセスにも使うことができます。詳細については、「複数テナントのアプリケーションに関するベストプラクティス」をお読みください。
カスタムデータベース接続の作成や構成には通常、Auth0 Dashboardが使用されます。データベース接続を作成してから、［Use my own database（独自のデータベースを使用する）］を有効にして、データベースのアクションスクリプトを編集できるようにします。カスタムデータベース接続の作成や構成には、Auth0 Management APIの接続作成エンドポイントとauth0ストラテジーを使うこともできます。
下の図が示すように、カスタムデータベース接続をログインワークフローに使用して、認証やユーザーのインポートを行うために、ユーザーのID情報が独自のレガシーIDストアから取得できるようにします。
すべてのデータベース接続タイプに共通なアーティファクトに加えて、カスタムデータベース接続を使用すると、アクションスクリプトを構成できるようになります。アクションスクリプトとは、レガシーIDストアとのやり取りに使用されるカスタムコードのことです。構成にどのスクリプトを選ぶかは、作成する接続の用途がレガシー認証なのか、それとも自動移行なのかに依存します。
アクションスクリプトは無名関数として実装できますが、無名関数にすると、デバッグを行う際に、生成されたコールスタックを例外的なエラー条件の結果として解釈するのが難しくなります。利便性を考慮して、アクションスクリプトには関数名を付けることをお勧めします。推奨される名前の例については、「カスタムデータベースのアクションスクリプト実行に関するベストプラクティス」をお読みください。
レガシー認証のシナリオでは、ユーザーレコードは新規作成されません。ユーザーは引き続きレガシーIDストアで管理され、ユーザーの認証時にAuth0はそのIDを使用します。カスタムデータベース接続は、ユニバーサルログインワークフローの外部でも使用されます。たとえば、レガシーのIDストアにいるユーザーに対してパスワード変更操作が行われると、接続のchangePasswordアクションスクリプトが呼び出されます。
自動移行
自動移行では、Auth0は新しいユーザーをAuth0管理のIDストア（データベース）内に作成します。Auth0がユーザーを認証する際には、Auth0管理のIDストアにあるIDが使用されます。これを行うために、Auth0は、レガシーIDストアに対照してユーザーが認証されることを要求します。この認証に成功した場合にのみ、Auth0はAuth0管理のデータベース内に新しいユーザーを作成します。新しいユーザーの作成には、認証中に提供されたのと同じIDとパスワードが使用されます。
自動移行のシナリオでは、ユーザーの作成は通常、ログインアクションスクリプトが完了した後で実行されます。ユーザーをレガシーIDストアから削除する際には、ログインスクリプト内でインライン操作として行うのではなく、独立処理として行うことをお勧めします。そうすることで、ユーザーを誤って削除したために、移行でエラー条件が発生することを防ぎます。
自動移行では、ユーザーは引き続きレガシーIDストアで管理され、必要に応じて削除やアーカイブを行うことができます。これに関する弊害は、ユーザーがAuth0から削除されても、レガシーデータストアに存在したままになることです。このときに、削除されたユーザーがログインしようとすると、ログインまたはユーザー取得スクリプトが実行され、そのユーザーがレガシーIDストアから再度移行されます。
ログインまたはユーザー取得スクリプトが完了する前か、レガシーストアが最終的に削除される前に、レガシーストアのユーザーIDに移行済のマークを付けて、意図的に削除したユーザーが思いがけず作成し直されてしまうことを防ぐようにお勧めします。
サイズ
アクションスクリプトの実装では、総サイズが100 KBを上回らないことをお勧めします。Auth0プラットフォームでパッケージングと転送が処理されるため、サイズが大きいほど遅延が長くなります。そして、これはシステムの性能にも影響を与えます。100 KBの制限には、requireステートメントの一部として参照された可能性のあるnpmモジュールは含まれません。