メインコンテンツへスキップ
このアーキテクチャ シナリオでは、B2B Authentication に関する汎用的なガイダンスを提供しています。これには、推奨されるベストプラクティスとして Universal Login の使用も含まれます。ここで提供するガイダンスとあわせて確認することをお勧めします。
ベストプラクティスAuth0 では多数の認証ワークフローをサポートしていますが、Auth0 Universal Login を使用するワークフローは、最適な機能とセキュリティ を提供するため、業界および Auth0 のベストプラクティスと見なされています。特に Universal Login は、シングルサインオン (SSO) を標準で提供 し、フィッシング や bucket brigade などの攻撃の軽減に役立ちます。そのため、ユーザーがパスワード認証情報を入力する場合は、可能な限りこれを優先する必要があります。さらに重要なのは、New Universal Login Experience が、Auth0 組織 機能の使用時にサポートされる唯一の仕組みであることです。
ユーザーを認証するには、第 1 認証要素の認証情報を処理する必要があります。これを Auth0 が行う場合でも、サードパーティの (IdP) が行う場合でも、Auth0 組織 機能を使用する際は、Auth0 の Universal Login Experience も使用する必要があります。
Auth0 では、Auth0 テナント ごとに認証済みユーザー コンテキストを 1 つのみサポートします。テナントで認証済みユーザー コンテキストを選択的に切り替えることはできません。ユーザー コンテキストを変更すると、アクティブな SSO セッションに影響が生じます。この影響は Auth0 組織 機能にも及びます。組織ごとのコンテキストがどうしても必要な場合は、複数の Auth0 テナント を本番環境にデプロイする必要があります。複数のテナントを使用すると、シングルサインオン (SSO) やユーザープロフィール管理などに影響が及ぶため、この方法を採る前に慎重に検討してください。

​
データベース接続

Hoekstra & Associates の例を使って、Auth0 のデータベース接続で認証されるユーザーに対して、この認証実装がどのような流れになるかを見てみましょう。ここで説明するワークフローの大部分は、通常、利用している技術スタックに対応する適切な Auth0 SDK またはライブラリで処理されます。
Architecture Scenarios - MOA - Isolated Users, Shared Apps, Database Login Flow
  1. Hoekstra & Associates の Jennifer はブラウザーを開き、Hoekstra & Associates の Travel0 Corporate Booking インスタンスにアクセスします。
    1. Jennifer がすでに Hoekstra & Associates の Travel0 Corporate Booking インスタンスのセッションクッキーを保持している場合、通常はシステムにログイン済みのため、ここで処理を終了します。詳細については、シングルサインオン を参照してください。
  2. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは、/authorize エンドポイントを呼び出してパラメーターを渡し、Authorization Code Flow (PKCE の有無は問いません) を使用して Travel0 の Auth0テナントにリダイレクトします。通常、これは Auth0 SDK またはサードパーティ製ライブラリを使用して行います：
    1. redirect_uri: https://hoekstra.corp.travel0.net/login/callback
    2. response_type: code
    3. state: このセッションで生成された一意の state
    4. scope: openid profile …
    5. ユーザーについて必要な情報に応じた、追加のOIDC スコープ。
    6. client_id: Hoekstra & Associates の Travel0 Corporate Booking インスタンス向けに、Travel0 の Auth0 テナントで作成されたアプリケーションに関連付けられたクライアントID。
    7. organization: 使用する Auth0 組織。組織が事前に判明している場合は、/authorize へのリクエストにこのパラメーターを含めることができます。このパラメーターは organization=organization_id の形式で指定します。ここで organization_id には、Auth0 テナント内の対応する Auth0 組織定義に関連付けられた識別子を設定します。あるいは、/authorize の呼び出しから organization パラメーターを省略し、Auth0 テナントを構成して、第1認証要素の認証プロセスの一環として、ユーザーに適切な組織を選択させることもできます。詳細については、組織の動作を定義するを参照してください。
      /authorize エンドポイントの呼び出しに organization パラメーターを含める場合は、Auth0 とのセッション期間中、一貫してこれを使用する必要があります。Organizations 機能では、選択された組織は Auth0 SSO セッションに関連付けられないため、このパラメーターを省略すると、ユーザーは常に目的の組織を選択するよう求められます。
  3. Travel0 Auth0テナントは、ユーザーから認証情報を取得するために /login にリダイレクトします。Jennifer が Hoekstra & Associates ですでに Database セッションを確立している場合、手順 3a と 4 はスキップされます。詳細については、シングルサインオンを参照してください。
    1. ブランディング で説明されているとおり、組織固有のブランドアセットを含めるように設定できる Universal Login ページが表示されます。
  4. ユーザーは認証情報を入力し、loginをクリックします。
  5. Travel0 Auth0テナントはユーザーの認証情報を確認し、有効な場合は Rules パイプラインが実行されます。認可 で説明されているように、Rules はアクセス制御の処理に使用できます。ユーザーの認証情報が無効な場合は、再入力を求められます。
    このオプションが指定されている場合、メンバーシップは自動的に割り当てられます。詳細については、組織の接続に Just-In-Time メンバーシップを付与するを参照してください。手動で割り当てられたメンバーシップの場合、ユーザーがその組織のメンバーとしてまだ割り当てられていないと、検証に失敗します。
  6. 第1認証要素での認証と Rules の実行が正常に完了すると、ユーザーは、手順 2 で渡された state と code が付与された redirect_uri (https://hoekstra.corp.travel0.net/login/callback) にリダイレクトされます。
  7. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは state を検証した後、https://auth.travel0.net/oauth/token にある Travel0 の Auth0テナントを呼び出し、code と client id、client secret を渡して、IDトークン を取得します。取得した IDトークンは、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 インスタンスのセッションクッキーを持っている場合、通常はそのままシステムにログインされるため、ここで処理は終了します。詳細は、シングルサインオン を参照してください。
  2. MetaHexa Bank 向けの Travel0 Corporate Booking インスタンスは、/authorize エンドポイントを呼び出してパラメーターを渡し、Authorization Code Flow (PKCE の有無を問わず) を使用して Travel0 Auth0 テナントにリダイレクトします。通常、これは Auth0 SDK またはサードパーティライブラリを使用して行われます。
    1. redirect_uri: https://metahexa.corp.travel0.net/login/callback
    2. response_type: code
    3. state: このセッションで生成された一意の state
    4. scope: openid profile …
    5. ユーザーについて必要な情報に応じて追加で必要になる OIDC Scopes
    6. client_id: MetaHexa Bank 向けの Travel0 Corporate Booking インスタンス用に、Travel0 Auth0 テナント内で作成されたアプリケーションに関連付けられたクライアントID。
    7. organization: 使用する Auth0 組織。組織が事前にわかっている場合は、/authorize へのリクエストにこのパラメーターを含めることができます。これは organization=organization_id の形式で指定し、organization_id には Auth0 テナント内の対応する Auth0 組織定義に関連付けられた識別子を設定します。あるいは、/authorize の呼び出しから organization パラメーターを省略し、第 1 要素認証の一部として適切な組織をユーザーに選択させるよう Auth0 テナントを設定することもできます。詳細は、Define Organization Behavior を参照してください。
      /authorize エンドポイントの呼び出しに organization パラメーターを含める場合は、Auth0 とのセッション中を通して一貫して使用する必要があります。組織 機能では、選択した組織は Auth0 の SSO セッションに関連付けられないため、このパラメーターを省略すると、ユーザーは常に目的の組織を選択するよう求められます。
    8. connection: MetaHexa Bank 向けに設定された Auth0 エンタープライズ接続の名前。
      ベストプラクティスconnection パラメーターは常に指定してください。指定しない場合、ユーザーは上流の IDプロバイダー (IdP) に関連付けられたエンタープライズ接続を選択する必要があり、UX の観点では余分な手順になります。
  3. Travel Auth0 テナントは、第 1 要素の認証情報を認証するために MetaHexa IdP にリダイレクトします。
    1. ログインページが表示され、ユーザーが認証情報を入力します。Amintha がすでに MetaHexa IdP とのセッションを持っている場合、手順 3a と 4 はスキップされます。詳細は、シングルサインオン (SSO) を参照してください。
  4. ユーザーが認証情報を入力し、login をクリックします。
  5. 第 1 要素の認証が正常に完了すると、Rules パイプラインが実行されます。Rules は、Authorization で説明されているように、アクセス制御の処理に使用できます。ユーザーの認証情報が無効な場合は、再入力を求められます。
このオプションを指定すると、メンバーシップは自動的に割り当てられます。詳細については、組織接続へのジャストインタイムメンバーシップの付与を参照してください。手動で割り当てるメンバーシップの場合、ユーザーがすでに組織のメンバーとして割り当てられていないと、検証に失敗します。
ステップ 6 から 8 は、データベース接続のシナリオで説明されている内容と同じですが、ユーザーは Jennifer ではなく Amintha で、Hoekstra & Associates の代わりに MetaHexa Bank (metahexa.corp.travel0.net) を使用します。

​
ソーシャル接続

ソーシャル接続を介した認証は、エンタープライズ接続 の場合と同様のパターンに従いますが、上流の IdP が特定の組織ではなくソーシャルプロバイダーに関連付けられている点が異なります。
Auth0 のソーシャル接続はテナント レベルで定義されます。通常、各ソーシャルプロバイダーにつき、Auth0 テナントごとに設定されるソーシャル接続は 1 つだけであり、これは Auth0 テナント全体に対する定義を表します。そのため、ユーザーが与えた同意は、Auth0 テナント内で定義されたすべての Auth0 組織に適用され、特定の 1 つの組織のみに適用されるものではありません。
ソーシャル接続では、ユーザーの分離を組織ごとに一貫した形でモデル化することはできません。Custom Social Connections を使用するなどして、ソーシャルプロバイダーに対して複数の接続を作成し、ユーザー分離をモデル化したくなるかもしれませんが、そのような方法は避けてください。このような戦略では、同じユーザー ID が複数の接続定義に作成されるおそれがあり、いずれ必ず問題を引き起こします。