シングルIDプロバイダー：ログアウト

複数テナントアーキテクチャのOrganizationからユーザーをログアウトすることについて説明します。

認証済みセッションが不要になった際に終了させるログアウトは、セキュリティ衛生の観点から望ましい実践です。ログアウト機能を提供することで、不正な第三者がセッションを「乗っ取る」可能性を軽減するなど、潜在的なセキュリティ上の問題を軽減できます。当社のアーキテクチャシナリオでは、B2Bログアウトに関する一般的なガイダンスを提供しています。こちらのガイダンスと併せて確認することをお勧めします。このシナリオのログアウトは他のシステムのログアウトとほぼ同じで、複雑さに関しても標準のドキュメントで説明されているのと同水準です。

​

データベース接続

以下の図では、Hoekstra & Associatesの例を使い、Auth0データベース接続を介して認証済みのユーザーを扱う際に一般的に遭遇するフローを示しています。このフローで何が起こるのかを詳しく見ていきましょう。説明にあるほとんどのワークフローは、通常、使用している技術スタックに関連するAuth0 SDKやライブラリによって処理されます。

1. Jenniferがlogoutをクリックします。

2. Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスは、以下のパラメーターを含むリダイレクトでブラウザーをhttps://auth.travel0.netのTravel0 Auth0テナントに送ります。

   1. returnTo：https://hoekstra.corp.travel0.net/logoutComplete

   2. client_id：Hoekstra & AssociatesのTravel0 Corporate Bookingインスタンスのために、Travel0 Auth0テナントで作成されたアプリケーションに関連付けられているクライアントID。

      ベストプラクティス

      Auth0では、アプリケーションを個別に定義した方が、returnTo URLの構成が簡単になります。この構成においては、入力されたURLを正しく検証するために、対応するclient_idが使用されます。詳細については、「プロビジョニング」を参照してください。

3. Travel0 Auth0テナントはユーザーのために構築したAuth0セッションを終了し、すべてのSSO情報を削除して、指定されたreturnTo URLにブラウザーをリダイレクトします。

4. Hoekstra & AssociatesのTravel Corporate Bookingインスタンスは、Jenniferが正常にログアウトしたことを通知するページを表示し、必要であれば再ログインできるボタンもおそらく表示します。

   1. この段階で、Travel0 Corporate Bookingインスタンスは、通常、ユーザーに関連づけられたアプリケーションセッションのクリーンアップも行います。

Auth0でのユーザーのSSOセッションを削除したくない場合は、Auth0テナント上にある/logoutエンドポイントへのリダイレクトを設定せずに、アプリケーションセッションを単に終了することができます。ユーザーはアプリケーションからログアウトされますが、Auth0でのSSOセッションは有効なままです。この場合、ユーザーに対して、Auth0テナントにログインしたままであること、もう一度［Login（ログイン）］をクリックしても第1認証の資格情報が要求されないことを知らせるとよいでしょう。

​

エンタープライズ接続

このシナリオでは、データベース接続を使用するときよりもログアウト実装が少し複雑になることがあります。アプリケーションからのみログアウトするか、アプリケーションからのログアウトがAuth0テナントからのログアウトも引き起こすようにするかを選択することができます。組織のIDプロバイダー（IdP）からのログアウトを許可するオプションもありますが、多くのアプリケーションでは、特にユーザーが他の企業アプリケーションにログインし続ける必要がある場合、これを避けることが一般的です。しかしこれを避けると、ユーザーがその後loginボタンをクリックした際に、第1要素の資格情報をインタラクティブに提供することなく、自動的に認証される可能性があります。このような機能性はユーザーが予期しない体験をもたらす可能性があるため、ユーザーに予め伝えることを検討してください。

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

1. Aminthaがlogoutをクリックします。

2. Metahexa BankのTravel0 Corporate Bookingインスタンスは、以下のパラメーターを含むリダイレクトでブラウザーをhttps://auth.travel0.netのTravel0 Auth0テナントに送ります。

   1. returnTo：https://metahexa.corp.travel0.net/logoutComplete

   2. client_id：MetaHexa BankのTravel0 Corporate Bookingインスタンスのために、Travel0のAuth0テナントで作成されたアプリケーションに関連付けられているクライアントID。

   3. federated：MetaHexa Bank IdPからユーザーをログアウトする際に使用された任意のパラメーター。指定された場合、ブラウザーはMetaHexa Bank IdPに関連付けられた/logoutエンドポイントにリダイレクトされ、ブラウザーをTravel0 Auth0テナントにリダイレクトで戻す前にユーザーのセッションを終了します。

      ベストプラクティス

      Auth0では、アプリケーションを個別に定義した方が、returnTo URLの構成が簡単になります。この構成においては、入力されたURLを正しく検証するために、対応するclient_idが使用されます。詳細については、「プロビジョニング」を参照してください。

ステップ3と4はデータベース接続のシナリオで説明された内容と同じです。Jenniferの代わりにAmintha、Hoekstra & Assciatesの代わりにMetaHexa Bank（metahexa.corp.travel0.net）を入れてください。

​

ソーシャル接続

ソーシャル接続の場合、ログアウトのパターンはエンタープライズ接続と類似していますが、アップストリームのIdPは特定の組織ではなく、ソーシャルプロバイダーに関連付けられます。ソーシャルプロバイダーを使ったフェデレーションログアウト機能は、破壊的なユーザー体験を引き起こすため、ほぼすべての場合に利用するべきではありません。