利用可能性はAuth0プランによって異なる
この機能が利用できるかどうかは、ご利用のAuth0プラン（または契約）によります。詳細については、「価格設定」をお読みください。
Webtask.ioとWebtask CLIには、2018年7月17日より前に作成されたテナントしかアクセスできません。それより新しいテナントをご利用のエンタープライズのお客様は、アカウント担当者にアクセス権をリクエストしてください。その他のリクエストには、Auth0お問い合わせフォームをご利用いただければ、個別に対応いたします。
- 認証 ：ユーザーを認証するのに、データベースをAuth0でのIDプロバイダーとして使用する（レガシー認証と呼ばれます）
- ユーザーのインポート ：自動移行（トリクルダウン移行またはレイジー移行）を使用する
- Auth0テナントへのプロキシアクセス ：Auth0のマルチテナントアーキテクチャを使用する
-
接続作成エンドポイントに
auth0ストラテジーを使用します。 -
［Auth0 Dashboard］>［Authentication（認証）］>［Database（データベース）］に移動し、［Use my own database（独自のデータベースを使用する）］ を有効にして、データベースのアクションスクリプトを編集できるようにします。
仕組み
下の図が示すように、ユニバーサルログインワークフローにカスタムデータベース接続を使用して、ユーザーのID情報が独自のレガシーIDストアから取得できるようにします。
ベストプラクティス
アクションスクリプトは無名関数として実装できますが、無名関数にすると、デバッグを行う際に、生成されたコールスタックを例外的なエラー条件の結果として解釈するのが難しくなります。利便性を考慮して、アクションスクリプトには関数名を付けることをお勧めします。
レガシー認証のシナリオ
レガシー認証のシナリオでは、ユーザーが初めてログインすると、新しいレコードがAuth0内に作成されますが、ユーザーのパスワードのハッシュはAuth0に保管されません。Auth0がユーザーを認証する際には必ず、レガシーIDストアとそれに含まれているIDが使用されます。カスタムのデータベース接続は、ユニバーサルログインワークフローの外部でも使用されます。たとえば、レガシーのIDストアにいるユーザーに対してパスワード変更操作が行われると、接続の
changePasswordアクションスクリプトが呼び出されます。自動移行のシナリオ
自動移行やトリクルダウン移行では、Auth0は新しいユーザーをAuth0管理のIDストア（データベース）内に作成します。その後、Auth0がユーザーを認証する際には必ず、Auth0管理のIDストアにあるIDが使用されます。これを行うために、Auth0は、レガシーIDストアに対照してユーザーが認証されることを要求します。この認証に成功した場合にのみ、Auth0は新しいユーザーを作成します。新しいユーザーの作成には、認証中に提供されたのと同じIDとパスワードが使用されます。ベストプラクティス
自動移行のシナリオでは、ユーザーの作成は通常、
loginアクションスクリプトが完了した後で実行されます。そのため、レガシーのidentity storeからのユーザー削除をインライン操作として（つまりloginスクリプト内で）行うのではなく、独立処理として行うことをお勧めします。そうすれば、移行中にエラー条件が発生し、ユーザーが誤って削除されてしまう事態を防ぐことができます。loginまたは/そしてgetUserスクリプトが実行され、そのユーザーがレガシーIDストアから再度移行されます。
ベストプラクティス
最終的なレガシーストアの削除に先立って、
loginやgetUserが完了する前に、レガシーユーザーIDを移行しておくことをお勧めします。サイズ
アクションスクリプトの実装では、総サイズが100 KBを上回ってはいけません。Auth0のサーバーレスWebtaskプラットフォームでパッケージングと転送が処理されるため、サイズが大きいほど遅延が長くなります。そして、これはシステムの性能にも影響を与えます。100 kBの制限には、requireステートメントの一部として参照された可能性のある
npmモジュールは含まれません。環境
アクションスクリプトは、サーバーレスWebtaskコンテナーのインスタンスでJavaScript関数を呼び出すことにより実行されます。これに関して、WebtaskコンテナーとAuth0認証サーバー（ご利用のAuth0テナント）による各種のアーティファクトと共に、特定の環境が提供されます。npmモジュール
Auth0のサーバーレスWebtaskコンテナーでは、さまざまなnpmモジュールを利用することができます。npmモジュールはアクションスクリプトのコード実装で総サイズを低減するだけでなく、予め構築された幅広い機能を活用できるようにします。
公開されている多くのnpmモジュールが、変更することなくそのままで使用できます。このリストは、潜在的なセキュリティ関連の懸念を調査した上でまとめられています。必要なnpmモジュールがそのまま使える形で提供されていない場合には、Auth0のサポートポータルまたはAuth0の担当者までリクエストを提出してください。Auth0がリクエストを検討して、適合性を判断します。プライベートリポジトリで提供されているnpmモジュールについては、その使用に関して、Auth0は現在サポートを提供していません。
変数
Auth0のアクションスクリプトは環境変数に対応しており、グローバルに使用可能なconfigurationオブジェクトと呼ばれるものを介して使うことができます。詳細については、「カスタムデータベース接続を作成する」の「構成パラメーターを追加する」セクションをお読みください。
ベストプラクティス
configurationオブジェクトは、読み取り専用として扱い、資格情報やAPIキーなど、外部identity storeへのアクセスに使う機密性の高い情報を保管するために使用します。そうすれば、アクションスクリプトで機密性の高い値をハードコード化しなくてすみます。globalオブジェクト
Auth0のサーバーレスWebtaskコンテナーは、各Auth0テナントに関連付けられているプールからプロビジョニングされます。コンテナーインスタンスはそれぞれglobalオブジェクトを使用可能にして、コンテナーインスタンス内で実行されるすべてのアクションスクリプトからアクセスできるようにします。globalオブジェクトは、コンテナーに一意のグローバル変数として動作し、コンテナーインスタンス内で実行されるすべてのアクションスクリプトが使用する情報や機能の定義に使うことができます。
つまり、ユーザー特定のリソースを除く、あらゆるリソースをキャッシュするために、globalオブジェクトを使用することができます。たとえば、ユーザー非特定の機能性を提供するサードパーティー（ログ）APIのアクセストークンを保管するのに使用します。または、独自のユーザー非特定のAPIに対する、Auth0で定義され、クライアント資格情報フローによって取得されたアクセストークンを保管するのに使用します。
アクションスクリプトは、すでに実行中のコンテナインスタンスだけでなく、新規作成され、続いてプールに追加される可能性のあるコンテナインスタンスでも実行できます。Auth0でのアクションスクリプトの実行には、コンテナアフィニティはありません。そのため、ユーザー固有の情報を
globalオブジェクトに保存することは避け、globalオブジェクト内で行う宣言を、必ず初期化にも対応したものにしてください。globalオブジェクトがリセットされます。そのため、コンテナーに関連付けられたglobalオブジェクト内のすべての代入宣言には、初期化のプロビジョニングも含まれる必要があります。
ベストプラクティス
柔軟なパフォーマンスを確保するために、Auth0はサーバーレスWebtaskコンテナを随時提供し、それらのコンテナは各種の再利用ポリシーの対象となります。一般的に、
globalオブジェクトの寿命は20分より短いと想定することをお勧めします。セキュリティ
カスタムAPIを使ってレガシーIDストレージにアクセスする
レガシーIDストレージを一般のアクセスから保護することは、ベストプラクティスとして推奨されています。たとえば、インターネットにデータベースを公開することは、SQLなどのデータベースインターフェイスが機能性の面で極めて開放的になるため、最小特権の原則（PoLP：Principle of Least Privilege）に違反することになります。ベストプラクティス
APIを実装してレガシーのidentity store（データベース）への最小権限を与えることをお勧めします。インターネットを介して全般にアクセスできるようにはしないでください。
globalオブジェクト内で再利用のためにキャッシュされます。APIは個別の保護されたエンドポイントを提供して、必要なレガシー管理の機能性（read user、change passwordなど）だけを専用に処理します。
ベストプラクティス
認証に成功し、適切なオーディエンスが含まれている場合、Auth0はデフォルトで任意のAPIのトークンを提供します。ルールを使ってアクセストークンの割り当てを制限し、レガシーのidentity store APIへのアクセスを制限すれば、
/authorizeへのリダイレクトが傍受されてAPIにオーディエンスが追加されるなど、不正使用を防止できるだけでなく、さまざまな攻撃ベクトルのシナリオを軽減できます。レガシーIDストレージにAllowListでアクセスする
レガシーIDストアへのアクセスに、カスタムのAPIと提供しているネイティブインターフェイスのどちらを使う場合でも、Auth0テナントに関連付けられているIPアドレスのリストを使って、アクセスを制限することが推奨されます。AllowListはレガシーIDストアへのアクセスを制限し、Auth0で定義されているカスタムデータベースのアクションスクリプトのみが許可されることを確実にします。Auth0 IPアドレスAllowListは、1つのリージョンに定義されたすべてのAuth0テナント間で共有されます。許可リストを、レガシーのIDストアへのアクセスを保護するための唯一の方法として使用することは、絶対にしないでください。認可されていないアクセスをユーザーに許してしまい、潜在的なセキュリティの脆弱性を発生させる恐れがあります。