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

​
データベース接続

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

​
ソーシャル接続

ソーシャル接続による認証は、エンタープライズ接続の場合とほぼ同じパターンに従いますが、上流の IdP は特定の organization ではなく、ソーシャルプロバイダーに関連付けられています。
Auth0 の ソーシャル接続 はテナントレベルで定義されます。通常、各ソーシャルプロバイダーについて、1 つの Auth0 テナントに設定される ソーシャル接続 は 1 つだけであり、これは Auth0 テナント全体に対する定義を表します。したがって、ユーザーが行った同意は、Auth0 テナント内で定義されたすべての Auth0 Organizations に適用され、特定の 1 つの organization だけに適用されるものではありません。
ソーシャル接続 では、organization ごとに一貫した形でユーザー分離をモデル化することはできません。カスタムソーシャル接続を使用して、1 つのソーシャルプロバイダーに対して複数の接続を作成し、ユーザー分離をモデル化したくなるかもしれませんが、そのような方法は避けてください。このような戦略では、同じ user ID が複数の接続定義に作成される可能性があり、将来的に確実に問題を引き起こします。