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

# マルチIDプロバイダー組織

> 各Auth0組織にAuth0接続が複数あるマルチIDプロバイダー（IdP）組織について説明します。

マルチIDプロバイダー（<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-2" href="/docs/ja-jp/glossary?term=idp" tip="IDプロバイダー（IdP）: デジタルIDを保存および管理するサービス。" cta="用語集の表示">IdP</Tooltip>）組織のシナリオでは、[Auth0組織](/docs/ja-jp/manage-users/organizations/organizations-overview)機能を使用するすべての組織が[Auth0接続](/docs/ja-jp/connections)を複数使用します。このシナリオの実装は、多くの点で[シングルIDプロバイダー組織の実装と重なります。](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations)実際、Auth0組織機能は、この2種類の組織の組み合わせや、その間の移行をサポートしています。ただし、追加で考慮すべき項目がいくつかあります。

## 接続

[認可](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization)の一部として通常含まれる情報に加え、ユーザーの第一要素認証が実行された特定の[Auth0接続](/docs/ja-jp/connections)に関する詳細が含まれます。明示的に求められるわけではありませんが、そのような情報をIDトークンおよび/またはアクセストークンにカスタムクレームとして加えることで、アクセス制御に使用できる追加のコンテキストをアプリケーションおよび/またはAPIに提供することができます。

以下の例で示すように、カスタムクレームは通常、Ruleの拡張性を通じて追加され、[`context`](/docs/ja-jp/customize/rules/context-object)オブジェクトを使用して接続の詳細にアクセスできます。

```javascript lines theme={null}
context.idToken['http://travel0.net/connection'] = context.connection;     // Connection name claim
context.accessToken['http://travel0.net/connection'] = context.connection; // Connection name claim
```

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  ルールのコンテキストオブジェクトは、ユーザーの第1認証に使用する接続のさまざまな要素（`connection`名、`connectionID`、`connectionStrategy`など）を提供します。これは、[ポリシーの一元管理](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization)に使用できる追加情報を提供することで、ルールの拡張性も高めます。
</Callout>

### データベース接続

Auth0では複数の[データベース接続とカスタムデータベース接続](/docs/ja-jp/connections/database)を[プロビジョン](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/provisioning)できますが、これらのタイプの接続を1つのAuth0組織に複数関連付けることは推奨されません。データベース接続とカスタムデータベース接続は現在、[Identifier-First認証](/docs/ja-jp/authenticate/login/auth0-universal-login/identifier-first)の重要なコンポーネントであるホーム領域検出をサポートしておらず、複数定義されると、ユニバーサルログインの新しいエクスペリエンスではその中から選択することができないためです。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  **ベストプラクティス**

  Auth0 Organizationでの使用に向けてカスタムデータベース接続を定義する際は、そのAuth0 Organizationに関連付けられているカスタムデータベース接続が常に1つであることを確認してください。
</Callout>

### エンタープライズ接続

エンタープライズアプリケーションで[エンタープライズフェデレーション](/docs/ja-jp/authenticate/enterprise-connections)を使用する場合、その認証プロファイルで[ホーム領域検出を使用したIdentifier-First認証](/docs/ja-jp/authenticate/login/auth0-universal-login/identifier-first)を有効化することができます。有効化されると、ホーム領域検出は既知のドメインからのメールアドレスを検出し、自動的に適切なWorkforceログインに送ります。

詳細については、「[組織のログインフロー](/docs/ja-jp/manage-users/organizations/login-flows-for-organizations)」の「[Identifier-First認証](https://auth0.com/docs/manage-users/organizations/login-flows-for-organizations#identifier-first-authentication)」セクションをお読みください。

### ソーシャル接続

マルチIDプロバイダー組織のシナリオでソーシャル接続を使用する場合には、[認証](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authentication)セクションに記載されている考慮事項以外に特に対処が必要な考慮事項はありません。