> ## 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プロバイダー：認証 > ここでは、マルチテナントアーキテクチャのOrganizationsによるユーザー認証について説明します。 弊社のアーキテクチャシナリオでは、推奨されるベストプラクティスとして[ユニバーサルログイン](/docs/ja-jp/authenticate/login/auth0-universal-login)の使用など、[B2B認証](/docs/ja-jp/get-started/architecture-scenarios/business-to-business/authentication)に関する汎用ガイダンスを提供しているため、ここに記載されるガイダンスと共に確認することをお勧めします。 **ベストプラクティス** Auth0は数々の認証ワークフローに対応していますが、中でもAuth0ユニバーサルログインを用いたワークフローは、[最高の機能性とセキュリティ](/docs/ja-jp/authenticate/login/universal-vs-embedded-login)を提供するため、業界とAuth0のどちらにおいてもベストプラクティスとみなされています。特に、ユニバーサルログインは、[そのままですぐに使えるSingle Sign On（SSO）](https://auth0.com/learn/how-to-implement-single-sign-on/)を提供し、[フィッシング](https://auth0.com/blog/all-you-need-to-know-about-the-google-docs-phishing-attack/)や[中間者攻撃](/docs/ja-jp/secure/security-guidance/prevent-threats)といった攻撃を軽減することから、ユーザーがパスワード資格情報を入力するあらゆる場面で推奨されます。[New Universal Loginエクスペリエンス](/docs/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/universal-experience)が、Auth0 Organizations機能の使用時に唯一サポートされているメカニズムであることも重要です。 ユーザーを認証するには、第1要素資格情報の処理が必要です。これがAuth0によって実行されるか、サードパーティのIDプロバイダー（IdP）によって実行されるかを問わず、Auth0 Organizations機能を使用する場合は、Auth0[ユニバーサルログインエクスペリエンス](/docs/ja-jp/authenticate/login/auth0-universal-login/universal-login-vs-classic-login/universal-experience)機能も使用する必要があります。 Auth0は、テナントにつき1つの認証されたユーザーコンテキストに対応しています。テナントが認証されたユーザーコンテキストを選んで切り替えることはできません。ユーザーコンテキストの変更は、アクティブなSSOセッションに影響を与えるため、Auth0 Organizations機能にも影響が及びます。どうしても組織ごとのコンテキストが必要な場合は、運用環境に複数のAuth0テナントをデプロイする必要があります。複数のテナントを使用すると、シングルサインオン（SSO）やユーザープロファイルの管理などに予測不可能な影響が及ぶため、事前に慎重に検討してください。 ## データベース接続 Hoekstra & Associatesの例を使って、Auth0データベース接続を介して認証されたユーザーを使った認証の実装の流れを見てみましょう。説明されているワークフローのほとんどは、通常、テクノロジースタックに関連するAuth0 SDKまたはライブラリーを使用して処理されます： Architecture Scenarios - MOA - Isolated Users, Shared Apps, Database Login Flow 1. Hoekstra & AssociatesのJenniferはブラウザを開き、Travel0 Corporate BookingのHoekstra & Associatesのインスタンスに移動します。 1. JenniferがTravel0 Corporate BookingのHoekstra & Associatesのインスタンスでセッションクッキーをすでに有する場合、通常システムにログインしているので、ここで終了となります。詳細については、[シングルサインオン](/docs/ja-jp/authenticate/single-sign-on)を参照してください。 2. Hoekstra & AssociatesのTravel0 Corporate Bookingのインスタンスは、[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)（[PKCE](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)の有無を問わず）を使用して、`/authorize`エンドポイントを呼び出し、[Auth0 SDK](/docs/ja-jp/libraries)またはサードパーティライブラリーを使用してパラメーターを渡すことにより、Travel0 Auth0テナントにリダイレクトします： 1. `redirect_uri`: [`https://hoekstra.corp.travel0.net/login/callback`](https://hoekstra.corp.travel0.net/login/callback) 2. `response_type`: `code` 3. `state`：このセッションで生成された一意の[state](/docs/ja-jp/secure/attack-protection/state-parameters) 4. `scope`: `openid profile` ... 5. ユーザーに関して必要な情報に応じた、追加で必要な[OIDCスコープ](/docs/ja-jp/get-started/apis/scopes/openid-connect-scopes)。 6. `client_id`：Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスのため、Travel0 Auth0テナントで作成されたアプリケーションに関連付けられているクライアントID 7. `organization`：使用するAuth0 Organization。組織が事前にわかっている場合は、`/authorize`への要求にこのパラメーターを含めることができます。これは、`organization=`organization\_idの形式で指定されます。organization\_idは、Auth0テナント内の対応するAuth0 Organization定義に関連付けられている識別子に設定されます。または、`/authorize`の呼び出しから`organization`パラメーターを省略し、第1要素認証の一部として適切な組織を選択するようにユーザーに求めるようAuth0テナントを構成することもできます。詳細については、「[Organizationの動作を定義する](/docs/ja-jp/manage-users/organizations/configure-organizations/define-organization-behavior)」を参照してください。 `/authorize`エンドポイントへの呼び出しに`organization`パラメーターが含まれている場合は、それをAuth0でのセッション中、一貫して使用する必要があります。Organizations機能は、選択された組織をAuth0 SSOセッションに関連付けることはしないため、パラメータを省略すると、希望の組織を選択するよう求めるプロンプトが毎回ユーザーに表示されます。 3. Travel0 Auth0テナントは、ユーザーから資格情報を収集するために`/login`にリダイレクトします。JenniferがすでにHoekstra & Associatesでデータベースセッションを有する場合、手順3aおよび4はスキップされます。詳細については、[シングルサインオン](/docs/ja-jp/authenticate/single-sign-on)を参照してください。 1. 「[ブランディング](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/branding)」で説明した通り、組織固有のブランドコラテラルを含めるように構成できる、ユニバーサルログインページが表示されます。 4. ユーザーが資格情報を入力し、［`login`（ログイン）］をクリックします。 5. Travel0 Auth0テナントは、ユーザーのクレデンシャルをチェックします。有効な場合は、[ルール](/docs/ja-jp/customize/rules)パイプラインが実行されます。ルールは、「[認可](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization)」で説明した通り、アクセス制御を取り扱うために使われます。ユーザーの資格情報が無効な場合には、ユーザーに再入力が要求されます。 このオプションを指定した場合、メンバーシップが自動的に割り当てられます。詳細については、「[Organizationの接続にジャストインタイム（JIT）メンバーシップを付与する](/docs/ja-jp/manage-users/organizations/configure-organizations/grant-just-in-time-membership)」を参照してください。[手動でメンバーシップを割り当て](/docs/ja-jp/manage-users/organizations/configure-organizations/assign-members)た場合、ユーザーがすでにOrganizationのメンバーとして割り当てられていないと、検証が失敗します。 6. 第1要素認証とルールの実行が成功すると、ユーザーは手順2で渡された`state`と`code`とともに、`redirect_uri`（[`https://hoekstra.corp.travel0.net/login/callback`](https://hoekstra.corp.travel0.net/login/callback)）にリダイレクトされます。 7. Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスが`state`を検証し、[`https://auth.travel0.net/oauth/token`](https://auth.travel0.net/oauth/token)でTravel0 Auth0のテナントを呼び出して、[IDトークン](https://auth0.com/docs/tokens/id-tokens)と引き換えに`code`とその`client id`および`client secret`を渡します。次に、IDトークンを使用して[`https://hoekstra.corp.travel0.net`](https://hoekstra.corp.travel0.net)のセッションが生成されます。 8. Hoekstra & AssociatesインスタンスのTravel0 Corporate Bookingインスタンスは、ユーザーに適切なページを表示します。 ## エンタープライズ接続 エンタープライズ接続を介した認証は、非常によく似たプロセスに従います。MetaHexa Bankの例を使って、MetaHexa Bankへのエンタープライズ接続を介して認証されたユーザーに対して、この認証実装がどのように行われるかを見てみましょう。繰り返しますが、説明されているワークフローのほとんどは、通常、テクノロジースタックに関連付けられている関連するAuth0 SDKまたはライブラリーを使用して処理されます。 Architecture Scenarios - MOA - Isolated Users, Shared Apps, Enterprise Login Flow 1. MetaHexa BankのAminthaがブラウザーを開き、MetaHexa BankのTravel0 Corporate Bookingのインスタンスに移動します。 1. AminthaがすでにMetaHexa BankのTravel0 Corporate Bookingのインスタンスのセッションクッキーを有する場合、通常システムにログインしているので、ここで終了します。詳細については、「[シングルサインオン](/docs/ja-jp/authenticate/single-sign-on)」を参照してください。 2. MetaHexa BankのTravel0 Corporate Bookingのインスタンスは、通常は[Auth0 SDK](/docs/ja-jp/libraries)またはサードパーティライブラリーを使用して、`/authorize`エンドポイントを呼び出してパラメーターを渡すことにより、[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)（[PKCE](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)の有無を問わず）を使用してTravel0 Auth0テナントにリダイレクトします： 1. `redirect_uri`：[`https://metahexa.corp.travel0.net/login/callback`](https://metahexa.corp.travel0.net/login/callback) 2. `response_type`: `code` 3. `state`：このセッションで生成された一意の[state](/docs/ja-jp/secure/attack-protection/state-parameters) 4. `scope`: `openid profile` ... 5. ユーザーに関して必要な情報に応じた、追加で必要な[OIDCスコープ](/docs/ja-jp/get-started/apis/scopes/openid-connect-scopes)。 6. `client_id`：MetaHexa BankのTravel0 Corporate Bookingインスタンスのために、Travel0のAuth0テナントで作成されたアプリケーションに関連付けられているクライアントID。 7. `organization`：使用するAuth0 Organization。組織が事前にわかっている場合は、`/authorize`への要求にこのパラメーターを含めることができます。これは、`organization=`organization\_idの形式で指定されます。organization\_idは、Auth0テナント内の対応するAuth0 Organization定義に関連付けられている識別子に設定されます。または、`/authorize`の呼び出しから`organization`パラメーターを省略し、第1要素認証の一部として適切な組織を選択するようにユーザーに求めるようAuth0テナントを構成することもできます。詳細については、「[Organizationの動作を定義する](/docs/ja-jp/manage-users/organizations/configure-organizations/define-organization-behavior)」を参照してください。 `/authorize`エンドポイントへの呼び出しに`organization`パラメーターが含まれている場合は、それをAuth0でのセッション中、一貫して使用する必要があります。Organizations機能は、選択された組織をAuth0 SSOセッションに関連付けることはしないため、パラメータを省略すると、希望の組織を選択するよう求めるプロンプトが毎回ユーザーに表示されます。 8. `connection`：MetaHexa Bank向けに構成された、Auth0 Enterprise Connectionの名称です。 **ベストプラクティス** `connection`パラメーターは必ず提供してください。そうしないと、ユーザーに対して、アップストリームのIDプロバイダー（IdP）に関連付けられたエンタープライズ接続を選択することが求められるため、ユーザーの手順が増え、UXが損なわれます。 3. Travel Auth0テナントは、第1要素の資格情報を認証するためにMetaHexa IdPにリダイレクトします。 1. ログインページが表示され、ユーザーが資格情報を入力します。AminthaがすでにMetaHexa IdPとのセッションを有する場合、ステップ3aと4はスキップされます。詳細については、「[シングルサインオン（SSO）](/docs/ja-jp/authenticate/single-sign-on)」を参照してください。 4. ユーザーが資格情報を入力し、［`login`（ログイン）］をクリックします。 5. 第1要素認証が成功すると、[ルール](/docs/ja-jp/customize/rules)パイプラインが実行されます。ルールは、「[認可](/docs/ja-jp/get-started/architecture-scenarios/multiple-organization-architecture/single-identity-provider-organizations/authorization)」で説明した通り、アクセス制御を取り扱うために使われます。ユーザーの資格情報が無効な場合には、ユーザーに再入力が要求されます。 このオプションを指定した場合、メンバーシップが自動的に割り当てられます。詳細については、「[Organizationの接続にジャストインタイム（JIT）メンバーシップを付与する](/docs/ja-jp/manage-users/organizations/configure-organizations/grant-just-in-time-membership)」を参照してください。[手動でメンバーシップを割り当て](/docs/ja-jp/manage-users/organizations/configure-organizations/assign-members)た場合、ユーザーがすでにOrganizationのメンバーとして割り当てられていないと、検証が失敗します。 手順6から8は「[データベース接続](#database-connection)」シナリオと同じですが、ユーザーはジェニファーでなくてアミンサで、Hoekstra & AssociatesでなくMetaHexa Bank（`metahexa.corp.travel0.net`）が使われます。 ## ソーシャル接続 ソーシャル接続による認証は、[エンタープライズ接続](#enterprise-connection)に関連付けられている認証と同様のパターンに従いますが、アップストリームIdPは特定のorganizationではなくソーシャルプロバイダーに関連付けられます。 Auth0のソーシャル接続は、テナントレベルで定義されます。通常、Auth0テナントごと、ソーシャルプロバイダーごとに1つのソーシャル接続が構成され、これがAuth0テナント全体での定義となります。したがって、ユーザーによって提供された同意は、特定の1つの組織ではなく、Auth0テナントで定義されているすべてのAuth0 Organizationsに適用されます。 ソーシャル接続では、ユーザーの分離をorganizationごとに一貫してモデル化することはできません。[カスタムソーシャル接続](/docs/connections/social/oauth2)を使用するなどして、ソーシャルプロバイダーへの複数の接続を作成することで、ユーザーの分離をモデル化したくなる場合がありますが、これは行わないでください。こうした戦略により、複数の接続定義で同一のユーザーIDが作成されることになり、将来必ず問題が発生します。