Logout とは、不要になった認証済みセッションを終了し、権限のない第三者にセッションを「乗っ取られる」可能性を最小限に抑えることです。通常は、ユーザー向けに提供するユーザーインターフェースにログアウトのオプションを用意することで実現します。ユーザーがログインすると、複数種類のセッション (例: ローカルのアプリケーションセッション、Auth0 セッション、サードパーティの セッション) が作成されることがあり、ユーザーがLogoutオプションをクリックしたときに、どのセッションを終了する必要があるかを判断しなければなりません。
ログアウト時の挙動では、どのセッションが終了されるのかをユーザーに明確に示し、できればその後にログアウト完了を視覚的に確認できるようにしてください。
- ユーザーがログアウトを開始したとき、どのセッションを終了させるべきか。
- 終了したセッションの確認として、どのような情報をユーザーに提供すべきか。
- ログアウト完了後、ユーザーをどこにリダイレクトすべきか。
- ユーザーがログアウト処理を実行しなかった場合、セッションをどれくらいの時間維持するか。
- エンドユーザーが 1 つのアプリケーションからログアウトしたとき、そのユーザーのすべてのアプリケーションセッションもログアウトさせるべきか。
- ログアウト時に、組織の IDP とのセッションも終了させるべきか。
ユーザーがログインするたびに作成されるセッションの種類はさまざまであるため、ログアウトにもいくつかの種類があります。ローカルアプリケーションのログアウトは、そのアプリケーションとのセッションを終了します。一方、Auth0 のログアウトは Auth0 セッションを終了します。独自の IDP を使用している組織がある場合は、フェデレーテッドログアウト 戦略を検討し、それに応じて実装することをおすすめします。グローバルログアウト、つまり シングルログアウト (SLO) は、Auth0 セッションを終了するだけでなく、Auth0 セッションに依存しているアプリケーションにもログアウトのリクエストまたは通知を送信します。
アプリケーションが提供する機能や、シングルサインオン (SSO) のような機能の利用状況によって、必要なログアウトの種類や、ユーザーにどのような視覚的確認を提供すべきかの判断が変わります。どの選択肢を採用する場合でも、実装するログアウト処理では、どのセッションが終了されるのか、またログアウト処理がいつ完了したのかをユーザーに明確に示す必要があります。
あるアプリケーションのログアウト機能が、他のアプリケーションでも使用されている Auth0 SSO セッションを終了させる場合、未確定のトランザクションがあるとユーザーは作業内容を失うおそれがあります。作業内容が失われる可能性を最小限に抑えるため、このような状況に対応するために必要な機能を必ず追加してください。
ログアウト後のユーザーのリダイレクト先
ユーザーがログアウトすると、指定した場所にリダイレクトされます。この場所は logout redirect URL として指定し、 でパラメーターとして設定できます。
ログアウト後のリダイレクト先として使用する URL は、オープンリダイレクトの脆弱性を軽減するため、Auth0 Dashboard で許可リストに登録しておく必要があります。許可リストへの登録は、テナントレベルまたはアプリケーションレベルで行えます。
ユーザーがログアウトしたあとアプリケーションにリダイレクトされ、そのアプリケーションが、引き続きそのユーザーの有効なセッションを保持している Identity Provider にリダイレクトすると、ユーザーはアプリケーションにサイレントログインされます。そのため、ユーザーにはログアウト処理が正しく機能しなかったように見える場合があります。
セッションの自動終了
すべてのユーザーが手動でログアウトするとは限らないため、Auth0 では、セッションが長時間維持されすぎるのを防ぐ セッションタイムアウト も提供しています。この設定は Auth0 Dashboard で利用でき、設定も可能です。
シングルログアウト
フェデレーテッドログアウトを行う場合は、シングルログアウト (SLO) も導入したいことが多く、主なアプローチは2つあります。
SLOを導入するとシステムが複雑になる可能性があるため、追加の開発・保守コストをかける前に、本当に必要かどうかを十分に確認してください。
短期間で有効期限が切れるトークン
レート制限やパフォーマンスの低下を避けるため、Auth0 テナントへの呼び出し回数はできるだけ増やさないようにしてください。ベストプラクティスとしては、トークンの有効期限が切れていて、かつユーザーが何らかの操作を行った場合にのみ、新しいトークンを要求します。これにより、開いているだけで使われていないアプリケーションが、新しいトークンを取得するために継続的にポーリングし続けるのを防げます。
connection パラメーターを使用するエンタープライズ接続の一部として、ユーザーをそのユーザー自身の IdP に自動的に直接転送している場合、フェデレーテッドログアウト も行っていない限り、この手法は機能しなくなる可能性があります ログアウトサービスを構築する
もう1つの方法として、アプリケーションのセッションを追跡して破棄できるログアウトサービスを構築することもできます。各アプリケーションは、セッションを作成したときと削除したときに、ログアウトサービスに通知します。この (ログアウト) サービスは、すべてのアプリケーションのサーバー側セッションに直接アクセスしてそれらを直接破棄するか、各アプリケーションにバックチャネルで呼び出しを行い、セッションを削除するよう通知できる必要があります。
この方法は、ユーザーがログアウトしてから、すべてのアプリケーションで実際にログアウトされるまでの遅延が小さいため、非常に効果的です。ただし、複雑さが増し、実装に追加の開発時間が必要になる場合があります。また、システムに新しく追加されるアプリケーションもこのサービスに組み込まれるよう、何らかの仕組みが必要です。
フェデレーテッドログアウト
Federated User Logout は、アプリケーションで検討が必要になる場合があります。あなたまたは顧客がサードパーティのIdP (つまり、Database Identity Provider 以外のもの) を使用する場合、アプリケーションからログアウトする際に、ユーザーをIdPからもログアウトさせる必要があるかどうかを判断する必要があります。答えは、ユーザーが何を期待するかによって異なります。使用しているアプリケーションやIdPが顧客組織と密接に結び付いており、日常業務の中核となっている場合、アプリケーションからログアウトしたときにIdPからもログアウトされると、ユーザーにとって煩わしく感じられることがあります。そうでない場合は、IdPからもログアウトされることが当然と受け止められたり、場合によってはむしろ望ましいことさえあります。ほとんどのB2Bシナリオでは、ユーザーに対してフェデレーテッドログアウトを実行しないほうが望ましいと、当社の顧客は考えています。
プロジェクト計画ガイド
推奨する戦略の詳細をご確認いただけるよう、ダウンロードして参照できるPDF形式の計画ガイドを提供しています。
B2B IAM プロジェクト計画ガイド 
