独自のユーザーストアで認証する

データベースをIDプロバイダーとして使用してユーザーを認証する方法について説明します。

利用可否は Auth0 プランによって異なります

この機能を利用できるかどうかは、Auth0 プランまたはカスタム契約の内容によって異なります。詳しくは、Pricingをご覧ください。

次の目的で、独立した独自の (レガシー) ID データストアへのアクセスを提供する場合は、カスタムデータベース接続を使用します。

• 認証: Auth0 でデータベースをIDプロバイダーとして使用し、ユーザーを認証します。 (これはレガシー認証と呼ばれます。)
• ユーザーのインポート: 自動移行 (段階的移行または遅延移行) を使用します
• Auth0 テナントへのプロキシアクセス: Auth0 のマルチテナントアーキテクチャを使用します。

次のいずれかの方法で、カスタムデータベース接続を作成および設定できます。

1. auth0 戦略で Create connections エンドポイントを使用します。

2. Auth0 Dashboard > Authentication > Database に移動し、接続を作成して、データベースアクションスクリプトを編集できるよう Use my own database オプションを有効にします。

   

​

仕組み

以下の図に示すように、独自のレガシー ID ストアからユーザーのID情報を取得するために、Universal Login ワークフローの一部としてカスタムデータベース接続を使用します。

すべてのデータベース接続タイプに共通する要素に加えて、カスタムデータベース接続では、レガシー ID ストアと連携する際に使用するカスタムコードであるアクションスクリプトを設定できます。Auth0 は設定用のカスタムデータベースアクションスクリプトテンプレートを提供しており、使用するテンプレートは、レガシー認証用のカスタムデータベース接続を作成するか、自動移行用に作成するかによって異なります。

ベストプラクティス

アクションスクリプトは無名関数として実装することもできますが、無名関数を使用すると、例外エラー発生時に生成されるコールスタックを解釈しづらくなり、デバッグが難しくなります。そのため、各アクションスクリプトには関数名を付けることを推奨します。

​

レガシー認証シナリオ

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

カスタムデータベース接続は、Universal Login ワークフロー以外でも使用されます。たとえば、レガシー ID ストア内のユーザーに対してパスワード変更処理が行われると、接続の changePassword アクションスクリプトが呼び出されます。

​

自動移行シナリオ

自動移行または段階的移行では、Auth0 は Auth0 が管理する ID ストア (データベース) に新しいユーザーを作成します。それ以降、Auth0 は常に Auth0 管理の ID ストア内の ID を使用してユーザーを認証します。これを行うには、まず Auth0 がレガシー ID ストアに対してユーザーを認証する必要があり、それが成功した場合にのみ新しいユーザーが作成されます。新しいユーザーは、認証時に指定されたものと同じ id とパスワードで作成されます。

ベストプラクティス

自動移行シナリオでのユーザー作成は、通常 login アクションスクリプトの完了後に行われます。そのため、レガシー ID ストアからのユーザー削除をインライン操作 (つまり login スクリプト内) として実行しようとするのではなく、削除は独立したプロセスとして実行することを推奨します。これにより、移行プロセス中にエラーが発生した場合のユーザーの誤削除を防ぐことができます。

自動移行シナリオでは、ユーザーはレガシー ID ストアに残るため、必要に応じて削除またはアーカイブできます。このとき起こり得る副作用の 1 つは、ユーザーが Auth0 から削除されても、レガシー ID ストアには引き続き存在している場合です。この場合、削除されたユーザーによるログインをきっかけに login および/または getUser スクリプトが実行され、ユーザーが再びレガシー ID ストアから移行される可能性があります。

ベストプラクティス

login または getUser が完了する前、かつ最終的にレガシー ストアから削除する前に、レガシー ユーザー ID を移行済みとしてマークすることを推奨します。

​

サイズ

アクションスクリプト実装の合計サイズは、100 kB を超えないようにしてください。サイズが大きいほど、Auth0 のサーバーレス Webtask プラットフォームで行われるパッケージ化および転送処理によってレイテンシが増加し、システムのパフォーマンスに影響します。

100 kB の上限には、require 文で参照される npm モジュールは含まれません。

​

環境

Action スクリプトは、サーバーレスの Webtask コンテナのインスタンス内で、呼び出された一連の JavaScript 関数として実行されます。この際、特定の実行環境に加えて、Webtask コンテナと Auth0 認証サーバー (Auth0 テナント自体) の両方から提供される各種アーティファクトも利用できます。

​

npm モジュール

Auth0 のサーバーレス Webtask コンテナでは、幅広い npm モジュールを利用できます。npm モジュールを使用すると、アクションスクリプトの実装コード全体のサイズを削減できるだけでなく、あらかじめ用意された幅広い機能を利用できます。

一般公開されている多くの npm モジュールは、そのままサポートされています。この一覧は、潜在的なセキュリティ上の懸念がないかを確認したうえでまとめられています。標準ではサポートされていない npm モジュールが必要な場合は、Auth0 サポートポータル または Auth0 の担当者を通じてリクエストできます。Auth0 は、その適合性を判断するためにリクエストを評価します。現在、Auth0 ではプライベートリポジトリーの npm モジュールの使用はサポートされていません。

​

変数

Auth0 のアクションスクリプトは環境変数をサポートしており、グローバルに利用できる configuration オブジェクトを介してアクセスできます。詳細については、Create Custom Database Connections の「Add Configuration Parameters」セクションを参照してください。

ベストプラクティス

configuration オブジェクトは読み取り専用として扱い、外部 ID ストアへのアクセスに使用する認証情報や API キーなどの機密情報の保存に使用してください。これにより、セキュリティ上重要な値をアクションスクリプトにハードコードすることを防げます。

configuration オブジェクトは、テナント固有の値を持つ変数を定義できるため、採用している任意の Software Development Life Cycle (SDLC) 戦略をサポートする目的にも使用できます。これにより、実行するテナントに応じて変わる可能性のある値をアクションスクリプトにハードコードすることを防げます。

​

global オブジェクト

Auth0 のサーバーレス Webtask コンテナは、各 Auth0 テナントに関連付けられたプールからプロビジョニングされます。各コンテナインスタンスでは global オブジェクトを利用でき、同じコンテナインスタンス内で実行されるすべてのアクションスクリプトからアクセスできます。global オブジェクトは、そのコンテナに固有のグローバル変数として機能し、コンテナインスタンス内で実行されるすべてのアクションスクリプトで使用する情報や関数を定義するために使用できます。

つまり、global オブジェクトを使って、ユーザー固有ではない高コストなリソースをキャッシュできます。たとえば、ユーザー固有ではない機能を提供するサードパーティの (ロギング) API 用の アクセストークン を保存できます。または、Auth0 で定義し、Client Credentials Flow を通じて取得した、独自のユーザー固有ではない API のアクセストークンを保存することもできます。

アクションスクリプトは、すでに実行中の任意のコンテナインスタンス、または新しく作成されたコンテナインスタンス (その後プールに追加される可能性があります) で実行される場合があります。Auth0 では、アクションスクリプトの実行にコンテナアフィニティはありません。つまり、global オブジェクトにユーザー固有の情報を保存することは避け、global オブジェクト内で行う宣言には必ず初期化処理も含める必要があります。

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

ベストプラクティス

パフォーマンスの柔軟性を確保するため、サーバーレス Webtask コンテナは Auth0 でアドホックにプロビジョニングされ、さらにさまざまな再利用ポリシーの対象にもなります。一般に、global オブジェクトの寿命は 20 分を超えないものとして扱うことを推奨します。

​

セキュリティ

​

カスタムAPI経由でレガシーIDストレージにアクセスする

レガシーIDストレージを広範なアクセスから保護することは、推奨されるベストプラクティスです。たとえば、データベースをインターネットに直接公開すると、非常に深刻な問題を招くおそれがあります。SQL などのデータベースインターフェイスは機能的に非常に多くの操作を許可するため、セキュリティにおける最小権限の原則に反します。

ベストプラクティス

レガシーIDストア (データベース) への広範なアクセスをインターネット経由で単純に開放するのではなく、最小権限を実現するためのAPIを実装することを推奨します。

代替手段として、各アクションスクリプトから呼び出せる、アクセストークンで保護されたシンプルな (カスタム) APIを作成できます。これがレガシーIDストアへのインターフェイスとして機能します。次に、クライアントクレデンシャルグラントフローを使用してスクリプト内からアクセストークンを取得し、その後、パフォーマンス向上のために global オブジェクトにキャッシュして再利用できます。API では、必要なレガシー管理機能だけを実行する、限定された数の保護されたエンドポイント (たとえば read user、change password) を提供できます。

ベストプラクティス

デフォルトでは、認証に成功し、適切な audience を含めると、Auth0 は任意の API 向けのトークンを発行します。Rule を使用してアクセストークンの発行を制限し、レガシーIDストアAPIへのアクセスを制限することで、不正利用を防ぎ、/authorize へのリダイレクトが傍受されて API の audience が追加されるようなケースを含む、複数の攻撃ベクトルを軽減できます。

​

レガシー ID ストレージへのアクセスを許可リストで制限する

カスタム API を使用してレガシー ID ストアへのアクセスを管理する場合でも、提供されているネイティブ インターフェイスを使用する場合でも、Auth0 テナントに関連付けられた IP アドレスのリストにアクセス元を制限してください。許可リストを使用すると、Auth0 で定義されたカスタム データベース アクションスクリプトだけがレガシー ID ストアにアクセスできるようになります。

Auth0 の IP アドレス許可リストは、同じリージョン内のすべての Auth0 テナントで共有されます。レガシー ID ストアへのアクセス保護を許可リストのみに依存しないでください。そうすると、未承認のアクセスを許してしまう可能性があり、ユーザーに関する情報への不正アクセスにつながるセキュリティ上の脆弱性を招くおそれがあります。

​

詳細情報

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