シングルIDプロバイダー：認証
弊社のアーキテクチャシナリオでは、推奨されるベストプラクティスとしてユニバーサルログインの使用など、B2B認証に関する汎用ガイダンスを提供しているため、ここに記載されるガイダンスと共に確認することをお勧めします。
ベストプラクティス
Auth0は数々の認証ワークフローに対応していますが、中でもAuth0ユニバーサルログインを用いたワークフローは、最高の機能性とセキュリティを提供するため、業界とAuth0のどちらにおいてもベストプラクティスとみなされています。特に、ユニバーサルログインは、そのままですぐに使えるSingle Sign On（SSO）を提供し、フィッシングや中間者攻撃といった攻撃を軽減することから、ユーザーがパスワード資格情報を入力するあらゆる場面で推奨されます。New Universal Loginエクスペリエンスが、Auth0 Organizations機能の使用時に唯一サポートされているメカニズムであることも重要です。
ユーザーを認証するには、第1要素資格情報の処理が必要です。これがAuth0によって実行されるか、サードパーティのIDプロバイダー（IdP）によって実行されるかを問わず、Auth0 Organizations機能を使用する場合は、Auth0ユニバーサルログインエクスペリエンス機能も使用する必要があります。
Auth0は、テナントにつき1つの認証されたユーザーコンテキストに対応しています。テナントが認証されたユーザーコンテキストを選んで切り替えることはできません。ユーザーコンテキストの変更は、アクティブなSSOセッションに影響を与えるため、Auth0 Organizations機能にも影響が及びます。どうしても組織ごとのコンテキストが必要な場合は、運用環境に複数のAuth0テナントをデプロイする必要があります。複数のテナントを使用すると、シングルサインオン（SSO）やユーザープロファイルの管理などに予測不可能な影響が及ぶため、事前に慎重に検討してください。
データベース接続
Hoekstra & Associatesの例を使って、Auth0データベース接続を介して認証されたユーザーを使った認証の実装の流れを見てみましょう。説明されているワークフローのほとんどは、通常、テクノロジースタックに関連するAuth0 SDKまたはライブラリーを使用して処理されます：
Hoekstra & AssociatesのJenniferはブラウザを開き、Travel0 Corporate BookingのHoekstra & Associatesのインスタンスに移動します。
JenniferがTravel0 Corporate BookingのHoekstra & Associatesのインスタンスでセッションクッキーをすでに有する場合、通常システムにログインしているので、ここで終了となります。詳細については、シングルサインオンを参照してください。
Hoekstra & AssociatesのTravel0 Corporate Bookingのインスタンスは、認可コードフロー（PKCEの有無を問わず）を使用して、
/authorizeエンドポイントを呼び出し、Auth0 SDKまたはサードパーティライブラリーを使用してパラメーターを渡すことにより、Travel0 Auth0テナントにリダイレクトします：redirect_uri:https://hoekstra.corp.travel0.net/login/callbackresponse_type:codestate：このセッションで生成された一意のstatescope:openid profile...ユーザーに関して必要な情報に応じた、追加で必要なOIDCスコープ。
client_id：Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスのため、Travel0 Auth0テナントで作成されたアプリケーションに関連付けられているクライアントIDorganization：使用するAuth0 Organization。組織が事前にわかっている場合は、/authorizeへの要求にこのパラメーターを含めることができます。これは、organization=organization_idの形式で指定されます。organization_idは、Auth0テナント内の対応するAuth0 Organization定義に関連付けられている識別子に設定されます。または、/authorizeの呼び出しからorganizationパラメーターを省略し、第1要素認証の一部として適切な組織を選択するようにユーザーに求めるようAuth0テナントを構成することもできます。詳細については、「Organizationの動作を定義する」を参照してください。/authorizeエンドポイントへの呼び出しにorganizationパラメーターが含まれている場合は、それをAuth0でのセッション中、一貫して使用する必要があります。Organizations機能は、選択された組織をAuth0 SSOセッションに関連付けることはしないため、パラメータを省略すると、希望の組織を選択するよう求めるプロンプトが毎回ユーザーに表示されます。
Travel0 Auth0テナントは、ユーザーから資格情報を収集するために
/loginにリダイレクトします。JenniferがすでにHoekstra & Associatesでデータベースセッションを有する場合、手順3aおよび4はスキップされます。詳細については、シングルサインオンを参照してください。「ブランディング」で説明した通り、組織固有のブランドコラテラルを含めるように構成できる、ユニバーサルログインページが表示されます。
ユーザーが資格情報を入力し、［
login（ログイン）］をクリックします。Travel0 Auth0テナントは、ユーザーのクレデンシャルをチェックします。有効な場合は、ルールパイプラインが実行されます。ルールは、「認可」で説明した通り、アクセス制御を取り扱うために使われます。ユーザーの資格情報が無効な場合には、ユーザーに再入力が要求されます。
このオプションを指定した場合、メンバーシップが自動的に割り当てられます。詳細については、「Organizationの接続にジャストインタイム（JIT）メンバーシップを付与する」を参照してください。手動でメンバーシップを割り当てた場合、ユーザーがすでにOrganizationのメンバーとして割り当てられていないと、検証が失敗します。
第1要素認証とルールの実行が成功すると、ユーザーは手順2で渡された
stateとcodeとともに、redirect_uri（https://hoekstra.corp.travel0.net/login/callback）にリダイレクトされます。Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスが
stateを検証し、https://auth.travel0.net/oauth/tokenでTravel0 Auth0のテナントを呼び出して、IDトークンと引き換えにcodeとそのclient idおよびclient secretを渡します。次に、IDトークンを使用してhttps://hoekstra.corp.travel0.netのセッションが生成されます。Hoekstra & AssociatesインスタンスのTravel0 Corporate Bookingインスタンスは、ユーザーに適切なページを表示します。
エンタープライズ接続
エンタープライズ接続を介した認証は、非常によく似たプロセスに従います。MetaHexa Bankの例を使って、MetaHexa Bankへのエンタープライズ接続を介して認証されたユーザーに対して、この認証実装がどのように行われるかを見てみましょう。繰り返しますが、説明されているワークフローのほとんどは、通常、テクノロジースタックに関連付けられている関連するAuth0 SDKまたはライブラリーを使用して処理されます。
MetaHexa BankのAminthaがブラウザーを開き、MetaHexa BankのTravel0 Corporate Bookingのインスタンスに移動します。
AminthaがすでにMetaHexa BankのTravel0 Corporate Bookingのインスタンスのセッションクッキーを有する場合、通常システムにログインしているので、ここで終了します。詳細については、「シングルサインオン」を参照してください。
MetaHexa BankのTravel0 Corporate Bookingのインスタンスは、通常はAuth0 SDKまたはサードパーティライブラリーを使用して、
/authorizeエンドポイントを呼び出してパラメーターを渡すことにより、認可コードフロー（PKCEの有無を問わず）を使用してTravel0 Auth0テナントにリダイレクトします：redirect_uri：https://metahexa.corp.travel0.net/login/callbackresponse_type:codestate：このセッションで生成された一意のstatescope:openid profile...ユーザーに関して必要な情報に応じた、追加で必要なOIDCスコープ。
client_id：MetaHexa BankのTravel0 Corporate Bookingインスタンスのために、Travel0のAuth0テナントで作成されたアプリケーションに関連付けられているクライアントID。organization：使用するAuth0 Organization。組織が事前にわかっている場合は、/authorizeへの要求にこのパラメーターを含めることができます。これは、organization=organization_idの形式で指定されます。organization_idは、Auth0テナント内の対応するAuth0 Organization定義に関連付けられている識別子に設定されます。または、/authorizeの呼び出しからorganizationパラメーターを省略し、第1要素認証の一部として適切な組織を選択するようにユーザーに求めるようAuth0テナントを構成することもできます。詳細については、「Organizationの動作を定義する」を参照してください。/authorizeエンドポイントへの呼び出しにorganizationパラメーターが含まれている場合は、それをAuth0でのセッション中、一貫して使用する必要があります。Organizations機能は、選択された組織をAuth0 SSOセッションに関連付けることはしないため、パラメータを省略すると、希望の組織を選択するよう求めるプロンプトが毎回ユーザーに表示されます。connection：MetaHexa Bank向けに構成された、Auth0 Enterprise Connectionの名称です。ベストプラクティス
connectionパラメーターは必ず提供してください。そうしないと、ユーザーに対して、アップストリームのIDプロバイダー（IdP）に関連付けられたエンタープライズ接続を選択することが求められるため、ユーザーの手順が増え、UXが損なわれます。
Travel Auth0テナントは、第1要素の資格情報を認証するためにMetaHexa IdPにリダイレクトします。
ログインページが表示され、ユーザーが資格情報を入力します。AminthaがすでにMetaHexa IdPとのセッションを有する場合、ステップ3aと4はスキップされます。詳細については、「シングルサインオン（SSO）」を参照してください。
ユーザーが資格情報を入力し、［
login（ログイン）］をクリックします。第1要素認証が成功すると、ルールパイプラインが実行されます。ルールは、「認可」で説明した通り、アクセス制御を取り扱うために使われます。ユーザーの資格情報が無効な場合には、ユーザーに再入力が要求されます。
このオプションを指定した場合、メンバーシップが自動的に割り当てられます。詳細については、「Organizationの接続にジャストインタイム（JIT）メンバーシップを付与する」を参照してください。手動でメンバーシップを割り当てた場合、ユーザーがすでにOrganizationのメンバーとして割り当てられていないと、検証が失敗します。
手順6から8は「データベース接続」シナリオと同じですが、ユーザーはジェニファーでなくてアミンサで、Hoekstra & AssociatesでなくMetaHexa Bank（metahexa.corp.travel0.net）が使われます。
ソーシャル接続
ソーシャル接続による認証は、エンタープライズ接続に関連付けられている認証と同様のパターンに従いますが、アップストリームIdPは特定のorganizationではなくソーシャルプロバイダーに関連付けられます。
Auth0のソーシャル接続は、テナントレベルで定義されます。通常、Auth0テナントごと、ソーシャルプロバイダーごとに1つのソーシャル接続が構成され、これがAuth0テナント全体での定義となります。したがって、ユーザーによって提供された同意は、特定の1つの組織ではなく、Auth0テナントで定義されているすべてのAuth0 Organizationsに適用されます。
ソーシャル接続では、ユーザーの分離をorganizationごとに一貫してモデル化することはできません。カスタムソーシャル接続を使用するなどして、ソーシャルプロバイダーへの複数の接続を作成することで、ユーザーの分離をモデル化したくなる場合がありますが、これは行わないでください。こうした戦略により、複数の接続定義で同一のユーザーIDが作成されることになり、将来必ず問題が発生します。