メインコンテンツへスキップ
Auth0の組織機能を使用すると、単一のAuth0テナントをプロビジョニングして本番環境にデプロイできます。ごく複雑なアーキテクチャ シナリオを除けば、シングルサインオン (SSO) やユーザーのプロファイル管理などとの統合や運用が容易になるため、本番環境で使用するAuth0テナントは単一にすることを推奨します。実装によっては、Auth0テナントの設定や対応する統合に関して、追加で考慮すべき項目があります。 組織に関連付けられたブランディングは非常に重要です。ブランド資産を使用することで、ユーザーにとって見慣れた信頼できる環境を提供できるためです。また、認識しやすいブランド資産を使用することで、ユーザーが提供する情報 (たとえば認証情報) が安全かつ適切に取り扱われるという安心感も高まります。そのため、Auth0の既定のブランディングは置き換えることを推奨します。詳細については、ブランディングを参照してください。

​
組織

サポートする各組織ごとに、独立した Auth0 の組織を作成してください。この例では、Hoekstra & Associates を表す hoekstra 組織と、MetaHexa Bank を表す metahexa 組織を作成します。組織は、 から手動で、または Auth0 の を使用してプログラムで作成できます。

​
アプリケーション

組織テナントの実装方法に応じて、Auth0テナント内でアプリケーション定義を作成する際の選択肢は異なります。どの方法を選んだ場合でも、組織の動作はアプリケーションレベルで定義されます。 顧客ごとに個別の組織テナントをプロビジョニングする場合、通常はそれぞれに対応する独立したアプリケーション定義を Auth0 で作成する必要があります。この構成では通常、使用する Auth0 組織を識別する organization パラメーターと、アプリケーション固有の client_id パラメーターの両方を、/authorize エンドポイントへのリクエストに含めて送信します。詳しくは、認証を参照してください。
ベストプラクティス設定を簡素化し、セキュリティ分離を最大化するため、Auth0 ではアプリケーションを個別に定義してください。これにより、Allowed Callback URLs のような項目を個別に設定できるほか、最小権限の原則に従って、クライアントIDやクライアントシークレットの情報が露出する可能性を最小限に抑えられます。
また、Auth0 では単一のアプリケーション定義を使用することもサポートされています。この場合、ユーザーは第1要素の認証の一環として、必要な組織を指定するよう求められます。通常は共通のアプリケーション client_id を使用することになりますが、/authorize エンドポイントへのリクエストでは organization パラメーターは省略されます。

​
接続

次に、ユーザーの認証に使用する接続を定義します。この例では、Hoekstra & Associates に関連付けられたユーザー向けのデータベース接続と、MetaHexa Bank に関連付けられたユーザー向けのエンタープライズ接続を定義します。
ベストプラクティス単一のIDプロバイダー (IdP) を使用する組織では、さまざまなユースケースに柔軟に対応できるよう、定義した各組織に対して 1 つの接続を作成してください。たとえば、組織ごとに 1 つのデータベース接続または Custom Database 接続を用意すると、廃止された組織に関連付けられたユーザーを簡単に削除でき、さらに、パスワード複雑性の要件が異なる組織にも最大限柔軟に対応できます。
接続を定義したら、Auth0 Dashboard または Auth0 Management API を使用して、適切な Auth0 組織に割り当てることができます。詳細については、組織の接続を有効にするを参照してください。

​
ユーザー

データベース接続または Custom Database 接続以外の接続を介して認証されるユーザーは、Auth0 とは独立して、通常どおり外部の (IdP) にプロビジョニングされます。一方、データベース接続または Custom Database 接続を介して認証されるユーザーは、いくつかの方法でプロビジョニングできます。Auth0 Dashboard と Auth0 Management API を使用すると、Auth0 テナントにユーザーを直接作成できます。また、Automatic Migration と Bulk Migration もサポートされています。
Management API または Dashboard 経由でユーザーをプロビジョニングするには、少なくとも 1 つの Application に対して、データベース接続または Custom Database 接続を直接有効にする必要があります。組織に対してのみデータベース接続または Custom Database 接続を有効にしても十分ではありません。
その後、ユーザーは memberships を割り当てることで Auth0 の組織に関連付けられます。また、Auth0 の組織は、ユーザーの Membership を自動的に割り当てるように設定することも、手動で割り当てることもできます。
ユーザーに組織への Membership を手動で割り当てるには、そのユーザーに Auth0 で定義された ユーザープロフィール がすでに存在している必要があります。Membership を手動で割り当てるには、Auth0 テナントの Dashboard または Auth0 Management API を使用できます。

​
招待

Auth0 の組織機能では、メンバー招待もサポートされています。メンバー招待のワークフローでは、ユーザーをアプリケーションに招待すると、そのユーザーは自動的にプロビジョニングされ、メンバーシップも自動的に作成されます。

​
データベース接続

Hoekstra & Associates の例を使って、ユーザー招待の一環としてデータベース接続を使用する場合に、この実装がどのような流れになるかを見てみましょう。ここで説明するワークフローの大部分は、通常、使用している技術スタックに対応する Auth0 SDK またはライブラリを使用して処理します。
アーキテクチャシナリオ - MOA - 分離されたユーザー、共有アプリ、招待フロー（データベース接続）
  1. Hoekstra & Associates の Jennifer は、Hoekstra & Associates の Travel0 Corporate Booking インスタンスに代わって Travel0 の Auth0 テナントから送信されたメールを受け取ります。
    1. このメールは、組織メンバーを招待で説明されているとおりに送信されたもので、Auth0 Dashboard または Auth0 Management API のいずれかから送信がトリガーされた可能性があります。
  2. ジェニファーはメールを開き、その中のリンクをクリックします。これにより、ブラウザーは Hoekstra & Associates の Travel0 Corporate Booking インスタンスに遷移します。リンクで使用されるベース URL は Application Login URI として指定されており、これは Travel0 Auth0 テナント内にある Hoekstra & Associates の Travel0 Corporate Booking アプリケーション定義の一部です。
    1. リンクには organization パラメーターと organization_name パラメーターが含まれます。organization パラメーターには、ご利用の Auth0 テナント内の対応する Auth0 組織の ID が設定されます。これはステップ 3 で Auth0 テナントに転送されます。
    2. リンクには invitation パラメーターも含まれ、これもステップ 3 で転送されます。
  3. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは、通常 Auth0 SDK またはサードパーティのライブラリを使用して /authorize エンドポイントを呼び出し、次のようなパラメーターを渡すことで、Authorization Code Flow (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 スコープ。
    6. client_id: Hoekstra & Associates の Travel0 Corporate Booking インスタンス向けに、Travel0 の Auth0 テナントで作成されたアプリケーションに関連付けられたクライアントID。
    7. organization: 招待元の組織の ID。通常は、手順 2 で説明したメール内のリンクから取得します。organization=organization_id の形式で指定します。ここで organization_id は、Auth0 テナント内の対応する Auth0 組織定義に関連付けられた識別子です。
    8. invitation: 手順 2 で説明したとおり、メール内のリンクに関連付けられた追加の invitation パラメーター。
  4. Travel0 Auth0 テナントは、ユーザーからパスワードを取得するために /signup/invitation にリダイレクトします。
    1. Branding で説明しているように、組織固有のブランディング要素を表示するよう設定できる Universal Login ページが表示されます。
      Auth0 の組織機能に関連付けられた招待ワークフローでは、Auth0 との既存の SSO セッションは考慮されません。そのため、ユーザーがサインアップに招待された時点ですでにサインインしている場合でも、メール内のリンクをクリックすると、関連付けられた Universal Login ページが常に表示されます。
  5. ユーザーはパスワード (およびユーザー名などの追加の認証情報) を入力し、[続行] をクリックします。ユーザー ID には、ユーザーに関連付けられたメールアドレスが設定されており、変更できません。
  6. Travel0 の Auth0テナントで認証情報が確認されます。有効な場合、ユーザーはプロビジョニングされ、Auth0 の組織メンバーシップが設定されます。ユーザーは自動的に認証され、Rules パイプラインが実行されます。認可 で説明されているように、Rules はアクセス制御の処理に使用できます。
    1. ユーザーの認証情報が無効な場合、再入力を求められます。
  7. 認証情報の検証と Rules の実行が正常に完了すると、ユーザーは手順 3 で渡された state および code とともに、redirect_uri (https://hoekstra.corp.travel0.net/login/callback) へリダイレクトされます。
  8. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは state を検証した後、https://auth.travel0.net/oauth/token にある Travel0 Auth0 Tenant に対して code と自身の client id、client secret を送信し、IDトークン を取得します。次に、その IDトークンを使用して https://hoekstra.corp.travel0.net のセッションを生成します。
  9. Hoekstra & Associates の Travel0 Corporate Booking インスタンスでは、ユーザーに適切なページが表示されます。

​
エンタープライズ接続

MetaHexa Bank の例を使って、ユーザー招待の一部としてエンタープライズ接続を使用する場合に、この実装がどのように進むかを見てみましょう。ここでも、説明するワークフローの大部分は通常、利用している技術スタックに対応する Auth0 SDK またはライブラリで処理されます。
アーキテクチャシナリオ - MOA - 分離されたユーザー、共有アプリ、招待フロー（エンタープライズ接続）
  1. MetaHexa Bank の Amintha は、MetaHexa Bank 向けの Travel0 Corporate Booking インスタンスを代表して、Travel0 の Auth0 テナントから送信されたメールを受け取ります。
    1. このメールは、組織メンバーを招待 で説明されている方法で送信されており、Auth0 Dashboard または Auth0 Management API のいずれかによってトリガーされた可能性があります。
  2. Amintha はメールを開き、その中のリンクをクリックします。すると、ブラウザーは MetaHexa Bank の Travel0 Corporate Booking インスタンスに移動します。リンクで使用されるベース URL は Application Login URI として指定されており、これは Travel0 の Auth0 テナント内にある MetaHexa Bank 向け Travel0 Corporate Booking アプリケーション定義の一部です。
    1. リンクには organization および organization_name パラメーターが含まれます。organization パラメーターには、Auth0 テナント内の対応する Auth0 組織定義の ID が設定されます。これはステップ 3 の一部として Auth0 テナントに転送されます。
    2. リンクには invitation パラメーターも含まれており、これもステップ 3 の一部として転送されます。
  3. MetaHexa Bank の Travel0 Corporate Booking インスタンスは、通常は Auth0 SDK またはサードパーティライブラリを使用して、/authorize エンドポイントを呼び出し、次のようなパラメーターを渡すことで、Authorization Code Flow (PKCE ありまたはなし) を使って Travel0 の Auth0 テナントにリダイレクトします。
    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: 通常はステップ 2 で説明したメール内のリンクから取得される、招待元の組織の ID。organization=organization_id の形式で指定します。ここで organization_id には、Auth0 テナント内の対応する Auth0 組織定義に関連付けられた識別子が設定されます。
    8. invitation: ステップ 2 で説明した、メール内のリンクに関連付けられた追加の invitation パラメーター。
  4. Travel0 の Auth0 テナントは /invitation にリダイレクトし、そこで Amintha に対して、第1認証要素の認証情報を認証するため、まず MetaHexa IdP にリダイレクトされることが通知されます。
    1. ユーザーが確認すると、
    2. Auth0 は MetaHexa Bank の IdP インスタンスにリダイレクトし、そこで
    3. ログインページが表示され、ユーザーは認証情報を入力して login をクリックします。
  5. 成功すると、Auth0 組織メンバーシップが設定され、ユーザーは暗黙的に認証され、Rules パイプラインが実行されます。Rules は、認可 で説明されているように、アクセス制御の処理に使用できます。
ステップ 6 から 8 は データベース接続 のシナリオで説明されているものと同じですが、ユーザーは Jennifer ではなく Amintha であり、Hoekstra & Associates の代わりに MetaHexa Bank (metahexa.corp.travel0.net) が使用されます。

​
ソーシャル接続

ソーシャル接続経由の招待は、エンタープライズ接続の場合と同様のパターンに従いますが、アップストリーム IdP は特定の組織ではなく、ソーシャルプロバイダーに関連付けられます。ソーシャル接続の使用に関する追加の考慮事項については、認証を参照してください。