シングルIDプロバイダー：プロビジョニング

Auth0 Organizations （組織）機能を使用することによって、シングルAuth0テナントを運用環境への導入に向けて準備することができます。最も複雑なアーキテクチャのシナリオ以外のすべてについて、運用環境での使用にシングルAuth0テナントをプロビジョニングしておくことが推奨されます。そうすることで、シングルサインオン（SSO）やユーザープロファイル管理などの統合や使用が容易になります。実装によっては、Auth0テナントのセットアップや付随の統合に関して、いくつかの追加項目に対処する必要が出るかもしれません。

ブランドコラテラルを使用するとユーザーが理解し信頼する環境を提供できるため、組織に関連付けられているブランディングは極めて価値の高いものです。認知されているブランドコラテラルを使用することは、提供する情報（資格情報など）が安全で確実に扱われるというユーザーの確信が強まることにも繋がります。そのため、そのまま使えるデフォルトのAuth0ブランディングは、独自のブランディングと入れ替えるべきです。詳細については、「ブランディング」を参照してください。

Organizations

利用する各組織にはそれぞれ独立したAuth0 Organizationを作成する必要があります。この例では、Hoekstra & Associatesを代表する組織としてhoekstraを、MetaHexa Bankを代表する組織として metahexaを作成します。Auth0 Dashboardから手動で、あるいはAuth0 Management APIを使ってプログラムで組織の作成が可能です。

アプリケーション

組織のテナントの統合がどのように設計されているかによって、Auth0テナント内でアプリケーションの定義を作成する際のオプションが異なります。どのオプションを選択したとしても、組織の動作はアプリケーションレベルで定義されます。

各顧客に個別の組織テナントをプロビジョニングする場合には、一般的にそれぞれについてAuth0で独立したアプリケーションの定義が必要になります。その場合は通常、どのAuth0 Organizationを使うのかを特定する/authorizeエンドポイントの呼び出しの一部として、アプリケーション固有のclient_idパラメーターとorganizationパラメーターの双方が含まれます。詳細については、「認証」を参照してください。

ベストプラクティス

Auth0では、アプリケーションを個別に定義した方が、構成しやすいだけでなく、セキュリティのために最大限の分離を実現できます。個別に定義することで、許可されるCallback URLなどの項目を個別に設定することができ、最小権限の原則（PoLP）に従って、クライアントIDやクライアントシークレット情報が漏洩する危険を最小限に抑えることができます。

別の方法として、Auth0で1つのアプリケーションの定義を使用することもできます。この場合、第1要素の認証の一環として、ユーザーは必要な組織を指定するように要求されます。これには通常、共通のアプリケーション client_idが必要ですが、 organizationパラメーターは/authorizeエンドポイント宛ての呼び出しでは省略されます。

接続

次に、ユーザーの認証に使われる［Connections（接続）］を定義します。この例では、Hoekstra & Associatesの関連ユーザーのために［Database Connection（データベース接続）］、MetaHexa Bankの関連ユーザーのためには［Enterprise Connection（エンタープライズ接続）］を定義します。

ベストプラクティス

単一のIDプロバイダー（IdP）を使用している組織では、定義された組織ごとに接続を1つ作成して柔軟性を持たせ、多数のユースケースに対応します。たとえば、各組織につき1つのデータベース接続またはカスタムデータベース接続があれば、組織が閉鎖された場合に関連付けられているユーザーが簡単に削除できます。また、パスワードの複雑性に関して異なる要件を課している組織にとっても、柔軟性が高まります。

接続が定義されたら、Auth0 DashboardまたはAuth0 Management APIを使用して、適切なAuth0 Organizationにプロビジョニングされます。詳細は、「組織の接続を有効にする」をお読みください。

ユーザー

データベースやカスタムデータベース接続以外の接続で認証されたユーザーは、Auth0から独立した外部のIDプロバイダー（IdP）に標準的な方法でプロビジョニングされます。一方、データベースやカスタムデータベース接続で認証されたユーザーは、さまざまな方法でプロビジョニングされます。Auth0 DashboardやAuth0 Management APIを使用すると、Auth0テナントでユーザーを直接作成することができます。また、［Automatic Migration（自動移行）］と［Bulk Migration（一括移行）］にも対応しています。

Management APIまたはDashboardを介してユーザーをプロビジョニングするには、データベース接続またはカスタムデータベース接続を少なくとも1つのアプリケーションに対して直接有効にしなければなりません。データベース接続またはカスタムデータベース接続をOrganizationに対して有効にするだけでは、十分ではありません。

ユーザーは、メンバーシップを割り当てることによってAuth0 Organizationに関係付けられ、Auth0 Organizationを設定して、ユーザーのメンバーシップを自動で、または手動で、割り当てることができます。

ユーザーに手動で組織のメンバーシップを割り当てるためには、そのユーザーにAuth0で定義されたユーザープロファイルがなければなりません。メンバーシップを手動で割り当てるときは、Auth0 Tenant DashboardまたはAuth0 Management APIを使用します。

Invitation（招待）

Auth0 Organization機能は、Member Invitation（メンバーの招待）の使用にも対応しています。メンバー招待ワークフローでは、ユーザーをアプリケーションに招待すると、ユーザーが自動的にプロビジョニングされ、ユーザーのメンバーシップが自動的に生成されます。

データベース接続

Hoekstra & Associatesの例を使って、ユーザー招待の一部として使用されるデータベース接続にこの実装がどのように繋がっていくのかを見てみましょう。説明にあるワークフローのほとんどは通常、使用している技術スタックに関連するAuth0 SDKやライブラリーが処理するものです。

Hoekstra & Associateに勤めるジェニファーは、Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスの代理として、Travel0のAuth0テナントからメールを受信します。
1. メールは「組織メンバーを招待する」で説明した通り送信され、Auth0 DashboardとAuth0 Management APIのいずれかを使ってトリガーされた可能性があります。
ジェニファーはメールを開いて、提供されたリンクをクリックします。そうすると、ブラウザーにHoekstra & AssociatesのTravel0 Corporate Bookingインスタンスが表示されます。リンク内のベースURLはアプリケーションログイン URIとして指定されたもので、Travel0 Auth0 TenantのTravel0 Corporate BookingアプリケーションのHoekstra & Associatesのインスタンスの一部を構成します。
1. リンクにはorganizationとorganization_nameパラメーターが含まれます。organizationパラメーターは、Auth0テナント内で対応するAuth0 Organization定義のIDに設定されます。これは、手順3の一部でAuth0テナントへ転送されます。
2. このリンクにはまた、やはり手順3の一部として転送されるinvitationパラメーターも含まれます。
Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスは、/authorizeエンドポイントを呼び出して、通常はAuth0 SDKまたはサードパーティのライブラリを通して、以下に類似したパラメーターを渡すことにより、認可コードフロー（PKCEを使用または不使用）を使ってTravel0 Auth0 Tenantにリダイレクトします。
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：手順2の説明にあるように、通常はメール内のリンクを通して取得される招待側組織のID。organization=organization_idの形式で指定されます（organization_idは、Auth0 Tenantで、対応するAuth0 Organization定義と関連付けられている識別子）。
8. invitation：手順2の説明にあるように、メール内のリンクに関連付けられる追加のinvitationパラメーター。
Travel0 Auth0テナントは、/signup/invitationにリダイレクトしてユーザーからパスワード資格情報を収集します。
1. 「ブランディング」で説明した通り、組織固有のブランドコラテラルを表示するように設定できるユニバーサルログインページが表示されます。
  Auth0 Organizations機能に関連付けられた招待ワークフローは、Auth0でのSSOセッションを考慮しません。ユーザーが、サインアップするよう招待され、すでにサインインしている場合、メール内のリンクをクリックすると、関連するユニバーサルログインページが必ず表示されます。
ユーザーはパスワード（と、ユーザー名など、追加の資格情報）を入力して、［続行］をクリックします。ユーザーIDは、ユーザーに関連付けられているメールアドレスに設定され、ユーザーはこの設定を変更できません。
Travel0のAuth0テナントが資格情報を確認します。有効であれば、ユーザーがプロビジョニングされ、Auth0 Organizationのメンバーシップが設定されます。ユーザーは暗黙的に認証され、 Rulesのパイプラインが実行されます。ルールは、「認証」で説明した通り、アクセス制御を取り扱うために使われます。
1. ユーザーの資格情報が無効な場合には、ユーザーに再入力が要求されます。
資格情報のチェックとルールの実行が完了すると、ユーザーはredirect_uri（https://hoekstra.corp.travel0.net/login/callback）にリダイレクトされ、手順3のstateとcodeが渡されます。
Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスがstateを検証し、https://auth.travel0.net/oauth/tokenでTravel0 Auth0のテナントを呼び出して、 ID トークンと引き換えにcodeとそのクライアントIDおよびクライアントシークレットを渡します。その後IDトークンを使って https://hoekstra.corp.travel0.netのセッションが作成されます。
Hoekstra & AssociatesインスタンスのTravel0 Corporate Bookingインスタンスは、ユーザーに適切なページを表示します。

エンタープライズ接続

MetaHexa Bankの例を使って、ユーザー招待の一部として使用されるエンタープライズ接続にこの実装がどのように繋がっていくのかを見てみましょう。今回も、説明にあるワークフローのほとんどは通常、使用している技術スタックに関連するAuth0 SDKやライブラリーが処理するものです。

MetaHexa Bankに勤めるアミンサは、MetaHexa BankのTravel0 Corporate Bookingインスタンスの代理として、Travel0のAuth0テナントからメールを受信します。
1. メールは「組織メンバーを招待する」で説明した通り送信され、Auth0 DashboardとAuth0 Management APIのいずれかを使ってトリガーされた可能性があります。
Aminthaはメールを開いて、提供されたリンクをクリックします。そうすると、ブラウザーにMetaHexa BankのTravel0 Corporate Bookingインスタンスが表示されます。リンク内のベースURLはアプリケーションログイン URIとして指定されたもので、Travel0 Auth0 TenantのTravel0 Corporate BookingアプリケーションのMetaHexa Bankのインスタンスの一部を構成します。
1. リンクにはorganizationとorganization_nameパラメーターが含まれます。organizationパラメーターは、Auth0テナント内で対応するAuth0 Organization定義のIDに設定されます。これは、手順3の一部でAuth0テナントへ転送されます。
2. このリンクにはまた、やはり手順3の一部として転送されるinvitationパラメーターも含まれます。
MetaHexa BankのTravel0 Corporate Bookingインスタンスは、/authorizeエンドポイントを呼び出して、通常はAuth0 SDKまたはサードパーティのライブラリを通して、以下に類似したパラメーターを渡すことにより、認可コードフロー（PKCEを使用または不使用）を使ってTravel0 Auth0 Tenantにリダイレクトします。
1. redirect_uri：https://metahexa.corp.travel0.net/login/callback
2. response_type：code
3. state：このセッションで生成された一意の state
4. scope：openid profile ...
5. ユーザー関連情報をベースとした、必要な追加のOIDCスコープ
6. client_id：MetaHexa BankのTravel0 Corporate Bookingインスタンスのために、Travel0のAuth0テナントで作成されたアプリケーションに関連付けられているクライアントID。
7. organization：手順2の説明にあるように、通常はメール内のリンクを通して取得される招待側組織のID。organization=organization_idの形式で指定されます（organization_idは、Auth0 Tenantで、対応するAuth0 Organization定義と関連付けられている識別子）。
8. invitation：手順2の説明にあるように、メール内のリンクに関連付けられる追加のinvitationパラメーター。
Travel0 Auth0テナントは/invitationにリダイレクトして、そこでアミンサは第1要素の資格情報のためにMetaHexaのIdPにリダイレクトされることを知らされます。
1. ユーザーが同意すると
2. Auth0がMetaHexa BankのIdPインスタンスにリダイレクトし
3. ログインページが表示され、ユーザーは資格情報を入力してから［login（ログイン）］をクリックします。
成功すると、Auth0 Organizatioメンバーシップが設定され、ユーザーは暗黙的に認証されて、ルールパイプラインが実行されます。ルールは、「認証」で説明した通り、アクセス制御を取り扱うために使われます。

手順6から8は「データベース接続」シナリオと同じですが、ユーザーはジェニファーでなくてアミンサで、Hoekstra & AssociatesでなくMetaHexa Bank（metahexa.corp.travel0.net）が使われます。

ソーシャル接続

ソーシャル接続を介した招待は、エンタープライズ接続と似たパターンを使用しますが、アップストリームIdPは、特定の組織でなく、ソーシャルプロバイダーと関連付けられます。ソーシャル接続の使用に関して追加で考慮するべき内容については、「認証」を参照してください。

はじめに