ログアウト（B2B）

ログアウトとは、必要でなくなったときに認証済みセッションを終了するアクションです。これによって、権限を持たない第三者によるセッションの「乗っ取り」の可能性を最小限に抑えます。これを行うには通常、ユーザーに提供するユーザーインターフェイスでログアウトオプションをプロビジョニングします。ユーザーのログイン時には複数のセッションタイプ（ローカルアプリケーションセッション、Auth0セッション、サードパーティによるIDプロバイダーセッションなど）を作成することができます。ユーザーが［Logout（ログアウト）］オプションをクリックするときに、これらのセッションのうちどれを終了する必要があるかを決定しなければなりません。

ログアウト時の動作を設定する場合は、以下の点を考慮する必要があります。

• ユーザーがログアウトを開始したとき、どのセッションを終了するべきか？

• セッション終了の確認として、ユーザーにどのような情報を通知するべきか？

• ログアウト完了後、ユーザーはどこにリダイレクトされるべきか？

• ユーザーがログアウトプロセスをトリガーしない場合、セッションをどれくらいの間継続したいか？

• エンドユーザーは1つのアプリケーションセッションからログアウトする際に、すべてのアプリケーションセッションからログアウトする必要があるか？

• 組織のIdPを使用したセッションもログアウト時に終了する必要があるか？

ユーザーのログイン時に作成できるセッションには様々なタイプがあることを考えると、ログアウトにもいくつかのタイプが考えられます。ローカルアプリケーションログアウトはアプリケーションとのセッションを終了しますが、一方でAuth0ログアウトはAuth0セッションを終了します。独自のIｄPを使用している組織の場合、フェデレーションログアウト戦略を検討し、適宜実装することをお勧めします。グローバルまたはシングルログアウト（SLO）はAuth0セッションを終了するだけでなく、Auth0セッションを使うアプリケーションにログアウト要求/通知を送信します。

アプリケーションで提供される機能やシングルサインオン（SSO）などの機能を使用することは、どのタイプのログアウトが必要なのか、そして、どのような確認通知をユーザーに画面表示する必要があるのかについての決定に役立ちます。どのオプションを選択する場合でも、実装するログアウトプロセスに応じて、どのセッションが終了されているのか、さらに、いつログアウトプロセスが完了したのかを、ユーザーに明確に示す必要があります。

場合によっては、ユーザーがいずれかのアプリケーションからログアウトした際に、関連するすべてのアプリケーションからもログアウトすることが求められます。これにより複雑さが増すかもしれません。ただし、ユーザーが（データの機密性などの理由で）脆弱な状態になる可能性が懸念される場合は、シングルログアウトを見直し、適切に実装する必要があるでしょう。

ユーザーはログアウト後、任意の特定の場所にリダイレクトされます。この場所はログアウトのリダイレクトURLとして指定され、Auth0 Dashboardを介してパラメーターとして定義することができます。

ログアウト後のユーザーのリダイレクトに使用するURLは、オープンリダイレクトのセキュリティ脆弱性を軽減するために、Dashboardで許可リストに登録する必要があります。テナントまたはアプリケーションレベルで許可リストに登録することができます。

すべてのユーザーがログアウトプロセスを手動でトリガーするわけではないため、Auth0では、セッション時間があまりに長くならないよう、セッションのタイムアウトも設けています。この設定は、Auth0 Dashboardで行うことができます。

フェデレーションログアウトを行う場合、シングルログアウト（SLO）も合わせて実施することをお勧めします。これには主に2つのアプローチがあります。

これは、シングルログアウトの最も簡単なアプローチです。各アプリケーションは、ユーザーがシステムを使用できる時間を短く、たとえば5～10分に設定します。ユーザーが実行する各アクションで有効期限が切れた場合、新しいトークンの取得のために、Auth0へのリダイレクト（通常のWebアプリ）、またはサイレント認証（クライアント側のシングルページアプリケーション）が使用されます。通常、新しいトークンはシングルサインオン（SSO）セッションにより、サイレントに発行されます。しかし、ログアウト後は、SSOセッションが削除されるため、すべてのアプリケーションで新しいトークンをサイレントに取得することはできなくなり、ユーザーは資格情報を再入力しなければなりません。

もう一つの技術として、アプリケーションセッションの追跡と破棄ができるログアウトサービスの構築ができます。各アプリケーションは、ログアウトサービスがセッションの作成と削除を行った際に通知します。（ログアウト）サービスは、すべてのアプリケーションのサーバー側セッションに直接アクセスしてそれらを直接破棄するか、各アプリケーションに対してバックチャネル呼び出しを行い、セッションを削除する必要があることを通知する能力を持つ必要があります。

この技術は、ユーザーがログアウトを呼び出してからすべてのアプリケーションからログアウトされるまでのレイテンシーが低いため、非常に効果的です。ただし、これにより複雑さが増し、実装にさらなる開発時間がかかる可能性があります。また、システムに新しいアプリケーションが追加される際には、それらがこのサービスに追加されるようにする仕組みも必要です。

アプリケーションに、ユーザーのフェデレーションログアウトを取り入れることを検討する必要があるかもしれません。ご自身または顧客がサードパーティのIdP（すなわちデータベースIDプロバイダー以外）を使用する場合、ユーザーがアプリケーションからログアウトする際に、そのIdPからもログアウトする必要があるかどうかを検討する必要があります。答えはユーザーが何を期待するかによります。アプリケーションやIdPが顧客組織に密接に関連し、日常業務の中心的な部分を担う場合は、アプリケーションからログアウトする度にIdPからもログアウトされるとユーザーが煩わしく感じる可能性があります。そうでない場合は、IdPからのログアウトは予期されたことで、場合によっては望ましいことでさえあります。弊社のお客様は、ほとんどのB2Bシナリオで、ユーザーのフェデレーションログアウトを実行*しない*方が好ましいと考えています。

当社では、PDF形式の計画ガイダンスを提供しています。ダウンロードして、推奨される戦略の詳細を参照してください。