ログアウト（B2B）

B2B IAM実装のユーザーログアウト計画で考慮すべき事項。

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

​

ベストプラクティス

ログアウトの動作は、ユーザーがどのセッションを終了しようとしているかを明確にする必要があり、ログアウト後に視覚的な確認を表示することが望ましいです。

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

• ユーザーがログアウトを開始したとき、どのセッションを終了するべきか？
• セッション終了の確認として、ユーザーにどのような情報を通知するべきか？
• ログアウト完了後、ユーザーはどこにリダイレクトされるべきか？
• ユーザーがログアウトプロセスをトリガーしない場合、セッションをどれくらいの間継続したいか？
• エンドユーザーは1つのアプリケーションセッションからログアウトする際に、すべてのアプリケーションセッションからログアウトする必要があるか？
• 組織のIdPを使用したセッションもログアウト時に終了する必要があるか？

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

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

あるアプリケーションのログアウト機能によって、他のアプリケーションが使用しているAuth0 SSOセッションが終了された場合、ユーザーによって確定されていないトランザクションの作業内容が失われる可能性があります。このような状況に対処する機能を必ず追加し、作業内容が失われる可能性を最小限に抑えてください。

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

​

ログアウト後のユーザーの送信先

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

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

ログアウトしたユーザーがリダイレクトを通じてアプリケーションに戻され、アプリケーションがそのユーザーの有効なセッションを維持しているIDプロバイダーにリダイレクトした場合、ユーザーは、アプリケーションにサイレントにログインされます。これは、ユーザーにとっては、ログアウトが正しく実行できなかったように見えるかもしれません。

​

セッションの自動終了

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

​

シングルログアウト

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

SLOは、システムを複雑にし、開発・メンテナンスの手間を増やします。実施する前に、SLOが本当に必要かどうかを検討してください。

​

短命トークン

​

ベストプラクティス

レート制限と低パフォーマンスを避けるために、Auth0テナントへの呼び出しをしすぎないようにしてください。トークンが期限切れで、ユーザーがアクションを起こした場合のみ、新しいトークンを要求することがベストプラクティスです。これにより、単に開いているが使用されていないアプリケーションが新しいトークンを継続的にポーリングするのを回避できます。

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

エンタープライズ接続の一環として、接続パラメーターを使ってユーザーを自動的にユーザー独自のIdPに転送している場合は、フェデレーションログアウトも行わないと、この技術が壊れる可能性があります。

​

ログアウトサービスの構築

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

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

​

フェデレーションログアウト

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

​

プロジェクト計画ガイド

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

B2B IAM Project Planning Guide