メインコンテンツへスキップ
不要になった認証済みセッションを終了すること (ログアウト) は、セキュリティ衛生上のベストプラクティスです。ログアウト機能を提供することで、権限のない第三者によるセッションの「乗っ取り」の可能性をはじめ、さまざまな潜在的なセキュリティ上の問題を軽減できます。アーキテクチャ シナリオでは、ここでのガイダンスとあわせて確認することを推奨する、汎用的な B2B Logout のガイダンスも提供しています。このシナリオにおけるログアウトは、他の一般的なシステムでのログアウトとほぼ同じであるため、複雑さのレベルも標準ドキュメントで説明しているものと同程度です。

​
データベース接続

Hoekstra & Associates の例では、以下の図は、Auth0 データベース接続経由で認証されたユーザーを扱う際に一般的に発生するフローを示しています。何が起こるのか、このフローに沿って見ていきましょう。なお、ここで説明するワークフローの大部分は、通常、使用している技術スタックに対応する Auth0 SDK またはライブラリによって処理されます。
アーキテクチャ シナリオ - MOA - 分離されたユーザー、共有アプリ、ログアウト フロー
  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 ではアプリケーションを個別に定義することをおすすめします。これにより、対応する client_id が使用される returnTo URL を設定しやすくなり、指定された URL を適切に検証できます。詳しくは、Provisioning を参照してください。
  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 認証要素の認証情報の入力を求められない可能性があることを伝えるとよいでしょう。

​
Enterprise 接続

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

​
ソーシャル接続

ソーシャル接続のコンテキストでは、ログアウトはEnterprise 接続の場合と同様のパターンに従いますが、上流の IdP は特定の組織ではなく、ソーシャルプロバイダーに関連付けられます。フェデレーテッドログアウトをソーシャルプロバイダーで利用したいケースは、まずほとんどないでしょう。ユーザー体験への影響が大きすぎるためです。