> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Auth0 を使用してマルチテナントアプリケーションを保護する際のベストプラクティスについて説明します。

# マルチテナントアプリケーションのベストプラクティス

マルチテナンシーとは、サーバー上で稼働する単一のソフトウェアインスタンスを、複数のユーザーグループが利用できるようにするアーキテクチャアプローチです。マルチテナンシーを使用すると、共通の特性を持つユーザーをグループ化し、それぞれに異なる権限やアプリケーションへのアクセスレベルを付与できます。これにより、顧客、事業部門、その他の定義済みユーザーグループごとに最適化された体験を提供し、維持できます。

Auth0 では、マルチテナンシーを実装する最適な方法は [Auth0 Organizations](/ja/docs/manage-users/organizations/organizations-overview) です。必要に応じて、特定のビジネスユースケースに対応するために、従来の別のソリューションを使用することもできます。[business-to-business (B2B)](/ja/docs/get-started/architecture-scenarios/business-to-business) の製品やサービスを提供している場合は、ビジネスユーザー向けにマルチテナンシーを設定することがユースケースに適している場合があります。

以下のセクションでは、Auth0 でマルチテナンシーを実装するための選択肢について説明します。

<Warning>
  この記事では、アプリケーションにアクセスできるユーザーのグループを指すソフトウェアアーキテクチャ用語として「tenant」を使用しています。Auth0 のインスタンスを指す場合は、「Auth0 テナント」という用語を使用します。
</Warning>

<div id="auth0-organizations">
  ## Auth0 Organizations
</div>

ほとんどのマルチテナントのユースケースでは、Auth0 Organizations はお客様とユーザーの双方にとって理想的なソリューションです。Auth0 Organizations は、エンドユーザーがアクセスできる 1 つ以上のアプリケーションを持つ B2B 実装をサポートします。

B2B 実装の一般的な特徴は次のとおりです。

* ある企業が、自社の従業員向けに別の企業からライセンスを受けて利用する製品。
* 認証エクスペリエンスにおいて、それぞれ独自のフェデレーションとシンプルなブランディングを必要とする複数の組織。
* ユーザーグループごとに異なるアプリケーションアクセスレベル。

Auth0 Organizations を使用すると、固有のユーザーグループを作成し、[ロールベースアクセス制御](/ja/docs/manage-users/access-control/rbac)、[カスタマイズされたログインページとメールテンプレート](/ja/docs/manage-users/organizations/create-first-organization#customize-prompts-and-email-templates) などを通じて、それぞれに合わせた体験を提供できます。

Auth0 Organizations を使用してマルチテナンシーを実装する方法の詳細については、[Multiple Organization Architecture](/ja/docs/get-started/architecture-scenarios/multiple-organization-architecture) を参照してください。

<div id="legacy-solutions">
  ## レガシーソリューション
</div>

Auth0 Organizations がユースケースの要件を満たさない場合は、以下に示すレガシーソリューションを検討できます。特定の要件に最適なアプローチを選択するためのガイダンスについては、[Professional Services](/ja/docs/get-started/professional-services) チームにお問い合わせください。

レガシーソリューションには、次のようなものがあります。

* 各テナントを表すために Auth0 の接続を使用する。
* 各テナントを表すために Auth0 のアプリケーションを使用する。
* 各テナントを表すために Auth0 のテナントを使用する。
* テナントの詳細をユーザーのユーザープロファイルに保存する。

<div id="use-auth0-connections">
  ### Auth0接続を使用する
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  エンティティ制限が適用される場合があります。詳しくは、[Entity Limit Policy](/ja/docs/troubleshoot/customer-support/operational-policies/entity-limit-policy)を参照してください。Enterprise サブスクリプションをご利用の場合、エンティティ制限による制約は受けませんが、すでに数千の有効なクライアントを持つ接続による制約を受ける可能性があります。
</Callout>

各テナントを、それぞれ個別の Auth0 接続として表すことができます。

この方法では、次のようなシナリオに対応できます。

* テナントごとに、異なるパスワードポリシーなど、接続レベルで異なる要件がある。
* 異なる接続のユーザープールがある。たとえば、あるテナントではユーザーに username とパスワードでの認証を求める一方、別のテナントではユーザーにエンタープライズ <Tooltip tip="IDプロバイダー（IdP）: デジタルアイデンティティを保存および管理するサービス。" cta="用語集を表示" href="/ja/docs/glossary?term=IdP">IdP</Tooltip> 経由でのログインを求めることができます。

ユーザーに特定の接続経由でログインさせるには、[Auth0 Authentication API の Login エンドポイント](https://auth0.com/docs/api/authentication#login)を呼び出し、`connection` パラメーターを含めます。

<Warning>
  アプリケーションで [Lock](/ja/docs/libraries#lock) を使用している場合、1 つのアプリケーションでサポートされるデータベース接続は最大 50 個であることに注意してください。ソーシャル接続とエンタープライズ接続はこの制限の対象ではありませんが、引き続き [Entity Limit Policy](/ja/docs/troubleshoot/customer-support/operational-policies/entity-limit-policy) の対象です。
</Warning>

<div id="use-auth0-applications">
  ### Auth0 アプリケーションを使用する
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  エンティティ制限が適用される場合があります。詳しくは、[Entity Limit Policy](/ja/docs/troubleshoot/customer-support/operational-policies/entity-limit-policy)を参照してください。Enterprise サブスクリプションをご利用の場合、エンティティ制限による制約は受けませんが、すでに数千の有効なクライアントが設定されている接続によって制約を受ける可能性があります。
</Callout>

各テナントを、それぞれ別の Auth0 アプリケーションとして表すことができます。

この方法では、利用可能な接続など、テナントごとに異なる要件に応じて各 Auth0 アプリケーションを個別に設定できます。

アプリケーション内で、各ユーザーがどのテナントに属しているかを管理する必要があります。ユーザーがアプリケーションにログインしたら、その情報を読み取り、認証を完了するために適切な Auth0 アプリケーションに誘導する必要があります。

Auth0 の <Tooltip tip="Management API: お客様が管理タスクを実行できるようにする製品です。" cta="用語集を見る" href="/ja/docs/glossary?term=Management+API">Management API</Tooltip> を使用して複数のアプリケーションで接続を有効にするには、[接続の有効なクライアントを更新するエンドポイント](https://auth0.com/docs/api/management/v2/connections/patch-clients)を呼び出し、該当する接続 ID を渡します。

<div id="use-auth0-tenants">
  ### Auth0 テナントを使用する
</div>

各テナントを、それぞれ別の Auth0 テナントとして表すことができます。

このアプローチでは、テナントごとにアクセスを制限したうえで、ユーザーに <Tooltip tip="Auth0 Dashboard: サービスを設定するためのAuth0の主要な製品です。" cta="用語集を見る" href="/ja/docs/glossary?term=Auth0+Dashboard">Auth0 Dashboard</Tooltip> へのアクセスを共有できますが、その分、各テナントごとに Auth0 を個別に設定する必要があります。

つまり、各 Auth0 テナントの機能 (ブランディング、Actions、<Tooltip tip="Attack Protection: Auth0が提供する攻撃の検出と軽減のための機能です。これには、ブルートフォース攻撃対策、不審なIPのスロットリング、漏えいパスワードの検知、ボット検知、適応型多要素認証が含まれます。" cta="用語集を見る" href="/ja/docs/glossary?term=Attack+Protection">Attack Protection</Tooltip> など) をそれぞれ個別に管理することに加え、アプリケーション側でも複数の Auth0 設定をサポートする必要があります。

<div id="store-tenant-details-in-the-users-profile">
  ### ユーザーのユーザープロファイルにテナントの詳細を保存する
</div>

ユーザーのユーザープロファイルにテナントの詳細を保存しておけば、ユーザーのログイン後にアプリケーションでその情報を読み取れます。

この方法では、どのテナントに属しているユーザーでも、統一された構成 (利用可能な接続など) でログインできます。

これを実装するには、任意の識別子 (たとえば `"tenant": "customer-group-12345"`) を使って、ユーザーの Auth0 ユーザープロファイル内の [`app_metadata` object](/ja/docs/manage-users/user-accounts/metadata) にテナントの詳細を保存します。ユーザーのログイン後、アプリケーションは `tenant` 変数を取得し、返された値に応じた適切なバージョンを表示します。