Auth0 Organizations
ほとんどのマルチテナントのユースケースでは、Auth0 Organizations は、お客様とユーザーにとって最適なソリューションです。Auth0 Organizations は、エンドユーザーがアクセスできる 1 つ以上のアプリケーションを持つ B2B 実装をサポートします。 B2B 実装に共通する特徴には、次のようなものがあります。- 他社の従業員による利用を目的として、その企業にライセンス提供される製品。
- 認証体験において、それぞれ独自のフェデレーションと簡易的なブランディングを必要とする複数の組織。
- 異なるユーザーグループごとに異なるアプリケーションアクセスレベル。
レガシーソリューション
Auth0 Organizations がお客様のユースケースの要件を満たさない場合は、以下のレガシーソリューションを検討できます。お客様固有の要件に最適なアプローチを選ぶためのガイダンスについては、Professional Services チームまでお問い合わせください。 レガシーソリューションには、次のものがあります。- 各テナントを表すために Auth0 接続を使用する。
- 各テナントを表すために Auth0 アプリケーションを使用する。
- 各テナントを表すために Auth0 テナントを使用する。
- ユーザーのプロフィールにテナントの詳細を保存する。
Auth0 接続を使用する
エンティティの上限が適用される場合があります。詳しくは、Entity Limit Policyをご覧ください。Enterprise サブスクリプションをご利用の場合、エンティティ上限による制約は受けませんが、すでに数千の有効なクライアントが設定されている接続によって制約を受ける可能性があります。
- テナントごとに、パスワードポリシーが異なるなど、接続レベルで異なる要件がある。
- 異なる接続に属するユーザープールがある。たとえば、あるテナントではユーザー名/パスワード認証情報の入力が必要でも、別のテナントではエンタープライズ 経由でのログインが必要な場合があります。
connection パラメーターを含めます。
Auth0アプリケーションを使用する
エンティティ数の上限が適用される場合があります。詳しくは、Entity Limit Policyをご覧ください。Enterpriseサブスクリプションをご利用の場合、エンティティ数の上限による制約は受けませんが、すでに数千の有効なクライアントが有効化されている接続による制約を受ける可能性があります。
Auth0テナントを使用する
各テナントは、それぞれ個別のAuth0テナントとして表現できます。 この方法では、テナントごとにアクセスを制限したうえで、ユーザーにへのアクセスを共有できますが、テナントごとにAuth0を個別に設定する必要があります。 つまり、各Auth0テナントの機能 (Branding、Actions、など) を個別に管理する必要があるだけでなく、アプリケーション側でも複数のAuth0設定に対応しなければなりません。ユーザーのプロフィールにテナントの詳細を保存する
ユーザーのプロフィールにテナントの詳細を保存しておけば、ユーザーがログインした後に、アプリケーションでその情報を読み取れます。 この方法を使えば、どのテナントに属しているユーザーでも、統一された設定 (利用可能な接続など) でログインできます。 これを実装するには、任意の識別子 (たとえば"tenant": "customer-group-12345") を使って、ユーザーの Auth0 プロフィールの app_metadata オブジェクト にテナントの詳細を保存します。ユーザーがログインした後、アプリケーションで tenant 変数を取得し、返された値に応じた適切なバージョンを表示します。