Skip to main content
不要になった認証済みセッションを終了すること、つまりログアウトは、基本的なセキュリティ対策として重要です。ログアウト機能を提供することで、権限のない第三者にセッションを「乗っ取られる」リスクをはじめ、さまざまな潜在的なセキュリティ上の問題を軽減できます。アーキテクチャシナリオでは、汎用的なガイダンスとして B2B Logout を提供しています。ここでのガイダンスとあわせて確認することをお勧めします。このシナリオでのログアウトは、他のシステムでのログアウトとほぼ同じであるため、複雑さも標準ドキュメントで説明しているものと同程度です。

​
データベース接続

Hoekstra & Associates の例では、次の図は Auth0 のデータベース接続を介して認証されたユーザーを扱う際に一般的に発生するフローを示しています。何が起こるのかを確認するために、このフローを見ていきましょう。なお、ここで説明するフローの大部分は、通常、使用している技術スタックに対応する Auth0 SDK またはライブラリによって処理されます。
Architecture Scenarios - MOA - Isolated Users, Shared Apps, Logout Flow
  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 テナントで作成されたアプリケーションに関連付けられた Client ID。
      ベストプラクティスAuth0 ではアプリケーションを個別に定義しておくと、対応する client_id で使用される returnTo URL を設定しやすくなり、指定された URL を適切にバリデーションできます。詳しくは、プロビジョニング を参照してください。
  3. Travel0 Auth0 テナントは、ユーザーに代わって確立された Auth0 セッションを終了し、SSO 情報を削除して、ブラウザーを指定された returnTo URL にリダイレクトします。
  4. Hoekstra & Associates の Travel0 Corporate Booking インスタンスは、Jennifer にログアウトが正常に完了したことを知らせるページをレンダリングします。必要に応じて、再度ログインするためのボタンも表示されるでしょう。
    1. このステージでは、Travel0 Corporate Booking インスタンスは通常、ユーザーに関連付けられたアプリケーションセッションもクリーンアップする必要があります。
Auth0 とのユーザーの SSO セッションを削除したくない場合は、アプリケーションは Auth0 テナントの /logout エンドポイントにリダイレクトせず、アプリケーションセッションだけを終了できます。ユーザーはアプリケーションからはログアウトされますが、Auth0 との SSO セッションは引き続き維持されます。この場合、ユーザーには、引き続き Auth0 テナントにはログインしていること、および再度 login をクリックしても第 1 認証要素の資格情報の入力を求められない可能性があることを伝えるとよいでしょう。

​
エンタープライズ接続

このシナリオでは、ログアウト の実装はデータベース接続を使用する場合よりも少し複雑になることがあります。アプリケーションだけをログアウトすることも、アプリケーションからのログアウトにあわせて Auth0 テナントからもログアウトすることも、引き続き選択できます。ただし、組織の (IdP) からのログアウトを許可するという選択肢がある場合もあります。もっとも、ほとんどのアプリケーションではこれを避けます。特に、ユーザーが他の社内アプリケーションにもアクセスでき、そちらではログイン状態を維持しておく必要がある場合はなおさらです。ただし、これを避けると、その後ユーザーが login ボタンをクリックした際に、第一認証要素の資格情報を対話的に入力しなくても自動的に認証される可能性があります。この動作はユーザーにとって想定外のユーザーエクスペリエンスになり得るため、その旨を伝えることを検討してください。 MetaHexa Bank の例を使って、MetaHexa Bank へのエンタープライズ接続を通じて認証されたユーザーに対して、この ログアウト の実装がどのように進むかを見てみましょう。ここでも、説明するワークフローの大部分は通常、利用している技術スタックに対応する Auth0 SDK またはライブラリによって処理されます。
アーキテクチャシナリオ - MOA - 分離されたユーザー、共有アプリ、エンタープライズ ログアウト フロー
  1. Amintha が logout をクリックします。
  2. Travel0 Corporate Booking の MetaHexa Bank インスタンスは、次のパラメータを付けてブラウザーを https://auth.travel0.net の Travel0 Auth0 テナントにリダイレクトします。
    1. returnTo: https://metahexa.corp.travel0.net/logoutComplete
    2. client_id: Travel0 Auth0 テナントで MetaHexa Bank の Travel0 Corporate Booking インスタンス用に作成されたアプリケーションに関連付けられた Client ID。
    3. federated:  MetaHexa Bank の IdP からユーザーをログアウトさせるために使用する任意のパラメータです。指定すると、ブラウザーは MetaHexa Bank の IdP に関連付けられた /logout エンドポイントにリダイレクトされ、そこでユーザーのセッションが終了した後、Travel0 Auth0 テナントにリダイレクトされます。
      ベストプラクティスAuth0 ではアプリケーションを個別に定義すると、対応する client_id を使って指定された URL を正しくバリデーションできるよう、returnTo URL を設定しやすくなります。詳しくは、プロビジョニング を参照してください。
ステップ 3 と 4 は データベース接続 のシナリオで説明したものと同じですが、Jennifer の代わりに Amintha を、Hoekstra & Associates の代わりに MetaHexa Bank (metahexa.corp.travel0.net) を使用します。

​
ソーシャル接続

Social Connectionsのコンテキストでは、ログアウトはエンタープライズ接続に関連するものと似たパターンになりますが、上流のIdPは特定のorganizationではなく、ソーシャルプロバイダーに関連付けられます。フェデレーテッドログアウトをソーシャルプロバイダーで利用したいと思うことは、まずほとんどないでしょう。そうすると、ユーザー体験への影響が大きすぎるためです。