独自のユーザーストアを使用して認証する

以下のような目的で、独自の（レガシー）IDデータストアにアクセスを提供したい場合には、カスタムデータベース接続を使用します。

• 認証：ユーザーを認証するのに、データベースをAuth0でのIDプロバイダーとして使用する（レガシー認証と呼ばれます）

• ユーザーのインポート：自動移行（トリクルダウン移行またはレイジー移行）を使用する

• Auth0テナントへのプロキシアクセス：Auth0のマルチテナントアーキテクチャを使用する

カスタムデータベース接続を作成して構成するには、以下のタスクを実行します。

1. 接続作成エンドポイントにauth0ストラテジーを使用します。

2. ［Auth0 Dashboard］>［Authentication（認証）］>［Database（データベース）］に移動し、［Use my own database（独自のデータベースを使用する）］を有効にして、データベースのアクションスクリプトを編集できるようにします。

   

下の図が示すように、ユニバーサルログインワークフローにカスタムデータベース接続を使用して、ユーザーのID情報が独自のレガシーIDストアから取得できるようにします。

すべてのデータベース接続タイプに共通なアーティファクトに加えて、カスタムデータベース接続を使用すると、アクションスクリプトを構成できるようになります。アクションスクリプトとは、レガシーIDストアとのやり取りに使用されるカスタムコードのことです。Auth0は、構成にカスタムデータベースのアクションスクリプト用テンプレートを各種提供しています。どれを使用するかは、作成するカスタムデータベース接続の用途がレガシー認証なのか、それとも自動移行なのかに依存します。

レガシー認証のシナリオでは、ユーザーが初めてログインすると、新しいレコードがAuth0内に作成されますが、ユーザーのパスワードのハッシュはAuth0に保管されません。Auth0がユーザーを認証する際には必ず、レガシーIDストアとそれに含まれているIDが使用されます。

自動移行やトリクルダウン移行では、Auth0は新しいユーザーをAuth0管理のIDストア（データベース）内に作成します。その後、Auth0がユーザーを認証する際には必ず、Auth0管理のIDストアにあるIDが使用されます。これを行うために、Auth0は、レガシーIDストアに対照してユーザーが認証されることを要求します。この認証に成功した場合にのみ、Auth0は新しいユーザーを作成します。新しいユーザーの作成には、認証中に提供されたのと同じIDとパスワードが使用されます。

自動移行のシナリオでは、ユーザーは引き続きレガシーIDストアで管理され、必要に応じて削除やアーカイブを行うことができます。これに関する弊害は、ユーザーがAuth0から削除されても、レガシーIDストアに存在したままになることです。このときに、削除されたユーザーがログインしようとすると、loginまたは/そしてgetUserスクリプトが実行され、そのユーザーがレガシーIDストアから再度移行されます。

アクションスクリプトの実装では、総サイズが100 KBを上回ってはいけません。Auth0のサーバーレスWebtaskプラットフォームでパッケージングと転送が処理されるため、サイズが大きいほど遅延が長くなります。そして、これはシステムの性能にも影響を与えます。

アクションスクリプトは、サーバーレスWebtaskコンテナーのインスタンスでJavaScript関数を呼び出すことにより実行されます。これに関して、WebtaskコンテナーとAuth0認証サーバー（ご利用のAuth0テナント）による各種のアーティファクトと共に、特定の環境が提供されます。

Auth0のサーバーレスWebtaskコンテナーでは、さまざまなnpmモジュールを利用することができます。npmモジュールはアクションスクリプトのコード実装で総サイズを低減するだけでなく、予め構築された幅広い機能を活用できるようにします。

公開されている多くのnpmモジュールが、変更することなくそのままで使用できます。このリストは、潜在的なセキュリティ関連の懸念を調査した上でまとめられています。必要なnpmモジュールがそのまま使える形で提供されていない場合には、Auth0のサポートポータルまたはAuth0の担当者までリクエストを提出してください。Auth0がリクエストを検討して、適合性を判断します。プライベートリポジトリで提供されているnpmモジュールについては、その使用に関して、Auth0は現在サポートを提供していません。

Auth0のアクションスクリプトは環境変数に対応しており、グローバルに使用可能なconfigurationオブジェクトと呼ばれるものを介して使うことができます。詳細については、「カスタムデータベース接続を作成する」の「構成パラメーターを追加する」セクションをお読みください。

構成オブジェクトを使用すると、変数にテナント特定の値が定義できるようなるため、あらゆるソフトウェア開発ライフサイクル（SDLC）の戦略に対応させることができます。これにより、アクションスクリプトの実行テナントに依存して変わる値を、コードの中に埋め込む必要性が軽減されます。

Auth0のサーバーレスWebtaskコンテナーは、各Auth0テナントに関連付けられているプールからプロビジョニングされます。コンテナーインスタンスはそれぞれglobalオブジェクトを使用可能にして、コンテナーインスタンス内で実行されるすべてのアクションスクリプトからアクセスできるようにします。globalオブジェクトは、コンテナーに一意のグローバル変数として動作し、コンテナーインスタンス内で実行されるすべてのアクションスクリプトが使用する情報や機能の定義に使うことができます。

つまり、ユーザー特定のリソースを除く、あらゆるリソースをキャッシュするために、globalオブジェクトを使用することができます。たとえば、ユーザー非特定の機能性を提供するサードパーティー（ログ）APIのアクセストークンを保管するのに使用します。または、独自のユーザー非特定のAPIに対する、Auth0で定義され、クライアント資格情報フローによって取得されたアクセストークンを保管するのに使用します。

Webtaskコンテナーが再利用されるたびに、または、Webtaskコンテナーの新しいインスタンスでは、定義されているglobalオブジェクトがリセットされます。そのため、コンテナーに関連付けられたglobalオブジェクト内のすべての代入宣言には、初期化のプロビジョニングも含まれる必要があります。

レガシーIDストレージを一般のアクセスから保護することは、ベストプラクティスとして推奨されています。たとえば、インターネットにデータベースを公開することは、SQLなどのデータベースインターフェイスが機能性の面で極めて開放的になるため、最小特権の原則（PoLP：Principle of Least Privilege）に違反することになります。

別の方法としては、アクセストークンを使って保護できるように、簡単な（カスタムの）APIを作成して、それぞれのアクションスクリプトが呼び出せるようにします。これは、レガシーIDストアへのインターフェイスとして機能します。そして、スクリプト内からアクセストークンを取得するには、クライアント資格情報付与フローを使うことができます。性能を向上させるために、これはその後globalオブジェクト内で再利用のためにキャッシュされます。APIは個別の保護されたエンドポイントを提供して、必要なレガシー管理の機能性（read user、change passwordなど）だけを専用に処理します。

レガシーIDストアへのアクセスに、カスタムのAPIと提供しているネイティブインターフェイスのどちらを使う場合でも、Auth0テナントに関連付けられているIPアドレスのリストを使って、アクセスを制限することが推奨されます。AllowListはレガシーIDストアへのアクセスを制限し、Auth0で定義されているカスタムデータベースのアクションスクリプトのみが許可されることを確実にします。

• カスタムデータベース接続を作成する
• カスタムデータベースのアクションスクリプト用テンプレート
• カスタムデータベースのトラブルシューティング
• ユーザーのインポートとエクスポート