Organizationのログインフロー

Auth0 Organizationsを使用すると、B2B製品またはSaaSアプリケーションのリーダーは、マルチテナントアーキテクチャを構築し、識別トークンを適切に保存し、エンドユーザーのログインの手間を最小限に抑えることができます。

Auth0アプリケーションは、［Organizations（組織）］タブで個人、ビジネスユーザー、またはその両方の3つのユーザータイプをサポートするように構成できます。

消費者向けに明示的に設計されたアプリケーション（NetflixやSpotifyなど）では、Organization管理は必要ない可能性があります。個人を選択すると、ユーザーはアプリケーションに直接ログインし、Organizationのコンテキストは提供されません。

B2BまたはSaaSアプリケーション（SlackやJiraなど）はビジネスユーザーによってより適切に提供されるため、エンドユーザーはAuth0 Organizationのコンテキストでのみアプリケーションにアクセスできます。複数のOrganizationに所属するユーザーは、ログインフローの後にOrganization Pickerに誘導され、参加した最初の20の組織が表示されます。

エンドユーザーがアプリケーションで個人アカウントとビジネスアカウントの両方を保持する可能性がある場合は、[Both（両方）]を選択します。たとえば、Githubでは、個人用と業務用の両方のコードリポジトリが保存されることがよくあります。

アプリケーションのユーザータイプは、Auth0 Dashboard（上記参照）またはManagement APIを通じて構成できます。具体的には、クライアント更新エンドポイントのorganization_usageパラメーターを使用して、適切なユーザータイプを設定します。両方の方法の詳細については、「Organizationの動作を定義する」を参照してください。

［Business Users（ビジネスユーザー）］または［Both（両方）］を選択した後、ユーザーがアプリケーションにログインする際のエクスペリエンスをさらにカスタマイズできます。

ほとんどの組織では、［Prompt for Credentials（資格情報の入力を求める）］を選択してから、［Identifier First Authentication（Identifier First認証）］を有効にする必要があります。ユーザーがログインしようとしているOrganizationがすでにわかっている場合は、プロンプトなしオプションとOrganizationを用いたカスタム開発を使用すると、アプリでブランド化されカスタマイズされたログインフローを維持できます。管理者は、［Prompt for Organization（Organizationの入力を求める）］トグルを有効にして、ユーザーがログインするOrganizationを特定するように要求することで、エンドユーザーエクスペリエンスをさらに調整できます。

アプリケーションのログインフローは、Auth0 Dashboard（上述）またはManagement APIから構成できます。具体的には、クライアントの更新エンドポイントのorganization_require_behaviorパラメーターを使用して、適切なフローを設定します。両方の方法の詳細については、「Organizationの動作を定義する」を参照してください。

エンタープライズアプリケーションでエンタープライズフェデレーションを使用している場合は、認証プロファイルでホーム領域検出を使用したIdentifier First認証をアクティブ化できます。有効にすると、ホーム領域検出は既知のドメインからメールアドレスを検出し、適切なWorkforceログインに自動的に送信します。

このフローでは、ユーザーのメールドメインがエンタープライズ接続のIDプロバイダー（IdP）ドメインと一致しない場合に、1つのAuth0データベース接続をフォールバックとして使用できます。ユーザーには、組織のログインプロンプトではなくアプリケーションのログインプロンプトが表示され、アプリケーションで有効になっている接続がユーザーに表示されます。

ユーザーがメールアドレスを入力すると、Auth0は、このアプリケーションで有効になっているエンタープライズ接続とOrganizationsで有効になっているすべてのエンタープライズ接続とを照合します。一致が見つかった場合、ユーザーは関連付けられているIdPで認証するように指示されます。一致が見つからない場合、パスワードフィールドが表示されます。

Management APIを使用して、識別子優先認証を構成できます。具体的には、更新プロンプト設定エンドポイントのidentifier_firstパラメータを使用します。

ユーザーをOrganizationに直接招待または割り当てる代わりに、フェデレーションIdPで認証できるすべてのユーザーにOrganizationへのアクセスを許可することができます。これらのシナリオでは、Auth0は自動メンバーシップ設定を推奨します。

自動メンバーシップは通常、Organizationのログインプロンプトを使用してユーザーをログインするように指示することでトリガーされます。これにより、ユーザーに代わって接続と組織のパラメーターを渡すことができます。ログイン前にユーザーの希望する組織を判別できない場合、資格情報のプロンプトフローは、自動メンバーシップが構成されている唯一の組織にメンバーシップを付与します。

ただし、ユーザーをログインに送信する前に、ユーザーの希望する組織を判別できないシナリオもあります。この場合、前述の資格情報の入力を求めるフローを使用できますが、自動メンバーシップが有効化されている組織に対してこの接続が有効な接続として設定されている組織が1つだけある場合にのみ、ユーザーに組織のメンバーシップが付与されることに注意してください。

自動メンバーシップを構成するには、Management APIを使用できます。具体的には、[Modify an organization’s connection（組織の接続エンドポイントを変更する）]のassign_membership_on_loginパラメータを使用します。