メインコンテンツへスキップ
マルチテナンシーとは、サーバー上で稼働する単一のソフトウェアインスタンスを、複数のユーザーグループが利用できるようにするアーキテクチャアプローチです。マルチテナンシーを使用すると、共通の特性を持つユーザーをグループ化し、それぞれに異なる権限やアプリケーションへのアクセスレベルを付与できます。これにより、顧客、事業部門、その他の定義済みユーザーグループごとに最適化された体験を提供し、維持できます。 Auth0 では、マルチテナンシーを実装する最適な方法は Auth0 Organizations です。必要に応じて、特定のビジネスユースケースに対応するために、従来の別のソリューションを使用することもできます。business-to-business (B2B) の製品やサービスを提供している場合は、ビジネスユーザー向けにマルチテナンシーを設定することがユースケースに適している場合があります。 以下のセクションでは、Auth0 でマルチテナンシーを実装するための選択肢について説明します。
この記事では、アプリケーションにアクセスできるユーザーのグループを指すソフトウェアアーキテクチャ用語として「tenant」を使用しています。Auth0 のインスタンスを指す場合は、「Auth0 テナント」という用語を使用します。

​
Auth0 Organizations

ほとんどのマルチテナントのユースケースでは、Auth0 Organizations はお客様とユーザーの双方にとって理想的なソリューションです。Auth0 Organizations は、エンドユーザーがアクセスできる 1 つ以上のアプリケーションを持つ B2B 実装をサポートします。 B2B 実装の一般的な特徴は次のとおりです。
  • ある企業が、自社の従業員向けに別の企業からライセンスを受けて利用する製品。
  • 認証エクスペリエンスにおいて、それぞれ独自のフェデレーションとシンプルなブランディングを必要とする複数の組織。
  • ユーザーグループごとに異なるアプリケーションアクセスレベル。
Auth0 Organizations を使用すると、固有のユーザーグループを作成し、ロールベースアクセス制御、カスタマイズされたログインページとメールテンプレート などを通じて、それぞれに合わせた体験を提供できます。 Auth0 Organizations を使用してマルチテナンシーを実装する方法の詳細については、Multiple Organization Architecture を参照してください。

​
レガシーソリューション

Auth0 Organizations がユースケースの要件を満たさない場合は、以下に示すレガシーソリューションを検討できます。特定の要件に最適なアプローチを選択するためのガイダンスについては、Professional Services チームにお問い合わせください。 レガシーソリューションには、次のようなものがあります。
  • 各テナントを表すために Auth0 の接続を使用する。
  • 各テナントを表すために Auth0 のアプリケーションを使用する。
  • 各テナントを表すために Auth0 のテナントを使用する。
  • テナントの詳細をユーザーのユーザープロファイルに保存する。

​
Auth0接続を使用する

エンティティ制限が適用される場合があります。詳しくは、Entity Limit Policyを参照してください。Enterprise サブスクリプションをご利用の場合、エンティティ制限による制約は受けませんが、すでに数千の有効なクライアントを持つ接続による制約を受ける可能性があります。
各テナントを、それぞれ個別の Auth0 接続として表すことができます。 この方法では、次のようなシナリオに対応できます。
  • テナントごとに、異なるパスワードポリシーなど、接続レベルで異なる要件がある。
  • 異なる接続のユーザープールがある。たとえば、あるテナントではユーザーに username とパスワードでの認証を求める一方、別のテナントではユーザーにエンタープライズ 経由でのログインを求めることができます。
ユーザーに特定の接続経由でログインさせるには、Auth0 Authentication API の Login エンドポイントを呼び出し、connection パラメーターを含めます。
アプリケーションで Lock を使用している場合、1 つのアプリケーションでサポートされるデータベース接続は最大 50 個であることに注意してください。ソーシャル接続とエンタープライズ接続はこの制限の対象ではありませんが、引き続き Entity Limit Policy の対象です。

​
Auth0 アプリケーションを使用する

エンティティ制限が適用される場合があります。詳しくは、Entity Limit Policyを参照してください。Enterprise サブスクリプションをご利用の場合、エンティティ制限による制約は受けませんが、すでに数千の有効なクライアントが設定されている接続によって制約を受ける可能性があります。
各テナントを、それぞれ別の Auth0 アプリケーションとして表すことができます。 この方法では、利用可能な接続など、テナントごとに異なる要件に応じて各 Auth0 アプリケーションを個別に設定できます。 アプリケーション内で、各ユーザーがどのテナントに属しているかを管理する必要があります。ユーザーがアプリケーションにログインしたら、その情報を読み取り、認証を完了するために適切な Auth0 アプリケーションに誘導する必要があります。 Auth0 の を使用して複数のアプリケーションで接続を有効にするには、接続の有効なクライアントを更新するエンドポイントを呼び出し、該当する接続 ID を渡します。

​
Auth0 テナントを使用する

各テナントを、それぞれ別の Auth0 テナントとして表すことができます。 このアプローチでは、テナントごとにアクセスを制限したうえで、ユーザーに へのアクセスを共有できますが、その分、各テナントごとに Auth0 を個別に設定する必要があります。 つまり、各 Auth0 テナントの機能 (ブランディング、Actions、 など) をそれぞれ個別に管理することに加え、アプリケーション側でも複数の Auth0 設定をサポートする必要があります。

​
ユーザーのユーザープロファイルにテナントの詳細を保存する

ユーザーのユーザープロファイルにテナントの詳細を保存しておけば、ユーザーのログイン後にアプリケーションでその情報を読み取れます。 この方法では、どのテナントに属しているユーザーでも、統一された構成 (利用可能な接続など) でログインできます。 これを実装するには、任意の識別子 (たとえば "tenant": "customer-group-12345") を使って、ユーザーの Auth0 ユーザープロファイル内の app_metadata object にテナントの詳細を保存します。ユーザーのログイン後、アプリケーションは tenant 変数を取得し、返された値に応じた適切なバージョンを表示します。